From rodney.bates at wichita.edu Fri Feb 1 15:33:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 01 Feb 2008 08:33:43 -0600 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> Message-ID: <47A32DC7.5080909@wichita.edu> Ah, and this is a systematic way of ensuring the precondition a.n=b.n always holds. Does the MIN function hint at someday generalizing to not require this condition? That would be tidy, but seems like an awful lot of work, if it is never used. Tony Hosking wrote: > Hi Rodney, > > Yes, you are missing one crucial thing. Namely, that the front-end > compiler *carefully* uses these target integer simulations only with > values that are *explicitly* the same length. LONGINT and INTEGER are > different types. INTEGER is the *representation* type for all values > 32 bits or less. LONGINT is the representation type for only LONGINT > values. You cannot mix LONGINT with INTEGER in source code > expressions. They need to be converted explicitly using ORD/VAL. > Indeed, you are right that the interfaces should document that behavior > explicitly, or alternatively, perhaps the implementations should > <*ASSERT a.n=b.n*>. The change from the way PM3 does things was > necessary for the introduction of LONGINT. > > Hope this helps and sorry for the imprecision of documentation. > > On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: > >> Whenever I run across something this unbelievable, I figure I must >> be missing something. Can anybody tell me what? >> >> While working on making Pickles work on LONGINT, I have noted the >> following code snippets for doing target arithmetic at compile time: >> >> From m3-sys/m3middle/src/Target.i3: >> >> (* The bits of a target INTEGER (in 2's complement) are stored in >> an array of small host values, with the low order bits in the first >> element of the array. *) >> >> TYPE >> Int = (* OPAQUE *) RECORD >> n: CARDINAL; (* only bytes [0..n-1] contain valid bits *) >> x := IBytes{0,..}; (* default is Zero *) >> END; >> IBytes = ARRAY [0..7] OF IByte; >> IByte = BITS 8 FOR [0..16_ff]; >> >> From m3-sys/m3middle/src/TWord.m3: >> >> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >> VAR borrow := 0; n := MIN (a.n, b.n); >> BEGIN >> <*ASSERT n # 0*> >> r.n := n; >> FOR i := 0 TO n-1 DO >> borrow := a.x[i] - b.x[i] - borrow; >> r.x[i] := Word.And (borrow, Mask); >> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >> END; >> END Subtract; >> >> Unless the two values have equal numbers of bytes, Subtract just >> throws away the high bytes of the longer operand. It looks like >> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >> does this. >> >> It seems just about inconceivable that the arithmetic could be this >> broken and not have created many impossible-to-ignore bugs. SRC >> and pm3 do it differently. They have a single global variable that >> gives the used size of all CT target values. >> >> The only possible explanation I can think of is that the cm3 compiler >> happens never to pass two Target.Int values with different values of n. >> The relevant declarations give no hint of such a counter-intuitive >> requirement. If this is an essential precondition, it should be >> documented in the interfaces. >> >> -- >> ------------------------------------------------------------- >> 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 >> >> > > -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 1 20:57:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 14:57:15 -0500 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <47A32DC7.5080909@wichita.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> <47A32DC7.5080909@wichita.edu> Message-ID: <02DFFA0A-3768-413C-8D84-0354BC9CB08A@cs.purdue.edu> On Feb 1, 2008, at 9:33 AM, Rodney M. Bates wrote: > Ah, and this is a systematic way of ensuring the precondition > a.n=b.n always holds. Does the MIN function hint at someday > generalizing to not require this condition? Yes, that's the general idea. > That would be tidy, > but seems like an awful lot of work, if it is never used. Yeah, I played around with this a great deal and decided it wasn't worth the effort. > > Tony Hosking wrote: >> Hi Rodney, >> Yes, you are missing one crucial thing. Namely, that the front- >> end compiler *carefully* uses these target integer simulations >> only with values that are *explicitly* the same length. LONGINT >> and INTEGER are different types. INTEGER is the *representation* >> type for all values 32 bits or less. LONGINT is the >> representation type for only LONGINT values. You cannot mix >> LONGINT with INTEGER in source code expressions. They need to be >> converted explicitly using ORD/VAL. Indeed, you are right that >> the interfaces should document that behavior explicitly, or >> alternatively, perhaps the implementations should <*ASSERT >> a.n=b.n*>. The change from the way PM3 does things was necessary >> for the introduction of LONGINT. >> Hope this helps and sorry for the imprecision of documentation. >> On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: >>> Whenever I run across something this unbelievable, I figure I must >>> be missing something. Can anybody tell me what? >>> >>> While working on making Pickles work on LONGINT, I have noted the >>> following code snippets for doing target arithmetic at compile time: >>> >>> From m3-sys/m3middle/src/Target.i3: >>> >>> (* The bits of a target INTEGER (in 2's complement) are stored in >>> an array of small host values, with the low order bits in the >>> first >>> element of the array. *) >>> >>> TYPE >>> Int = (* OPAQUE *) RECORD >>> n: CARDINAL; (* only bytes [0..n-1] contain valid >>> bits *) >>> x := IBytes{0,..}; (* default is Zero *) >>> END; >>> IBytes = ARRAY [0..7] OF IByte; >>> IByte = BITS 8 FOR [0..16_ff]; >>> >>> From m3-sys/m3middle/src/TWord.m3: >>> >>> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >>> VAR borrow := 0; n := MIN (a.n, b.n); >>> BEGIN >>> <*ASSERT n # 0*> >>> r.n := n; >>> FOR i := 0 TO n-1 DO >>> borrow := a.x[i] - b.x[i] - borrow; >>> r.x[i] := Word.And (borrow, Mask); >>> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >>> END; >>> END Subtract; >>> >>> Unless the two values have equal numbers of bytes, Subtract just >>> throws away the high bytes of the longer operand. It looks like >>> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >>> does this. >>> >>> It seems just about inconceivable that the arithmetic could be this >>> broken and not have created many impossible-to-ignore bugs. SRC >>> and pm3 do it differently. They have a single global variable that >>> gives the used size of all CT target values. >>> >>> The only possible explanation I can think of is that the cm3 >>> compiler >>> happens never to pass two Target.Int values with different >>> values of n. >>> The relevant declarations give no hint of such a counter-intuitive >>> requirement. If this is an essential precondition, it should be >>> documented in the interfaces. >>> >>> -- >>> ------------------------------------------------------------- >>> 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 >>> >>> > > -- > ------------------------------------------------------------- > 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 Fri Feb 1 21:26:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 01 Feb 2008 21:26:30 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> References: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> Message-ID: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 2 00:57:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 18:57:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080201234353.F351E10D4655@birch.elegosoft.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> Message-ID: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> I just checked in support for full declaration of paramters even on imported procedures in the gcc-based backend. This is to support proper generation of stdcall calling convention on Windows. In the process of testing this I discovered that cm3 on non-Windows platforms now needs to build and ship both of the Windows x86 support libraries m3back and m3objfile, even though non-Windows platforms don't use or need them. This seems broken to me. It seems that cm3 has changed so that it now has these dependencies. Can we please undo this? -- I see no need to have to build these for non-x86 platforms that will never use them. On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 08/02/02 00:43:53 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Add parameter decls even for imported procedures, as per Jay > Krell's request > to support stdcall parameter passing mode on Windows. From jayk123 at hotmail.com Sat Feb 2 01:12:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:12:27 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...). Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well? Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly. ? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 01:19:05 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:19:05 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Actually it's slightly more real than I said. One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. Sometimes it uses the "extra" code, sometimes not. These are in a sense a limited form of cross build. Granted, if it was only for those three psuedo platforms, you wouldn't mind. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hosking at elego.deDate: Sat, 2 Feb 2008 00:12:27 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...).Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well?Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly.? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:22:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:22:56 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, that gnarly x86 backend will go away soon anyway -- it's probably never going to survive in the x86_64 universe and beyond! On Feb 1, 2008, at 7:19 PM, Jay wrote: > Actually it's slightly more real than I said. > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > Sometimes it uses the "extra" code, sometimes not. These are in a > sense a limited form of cross build. Granted, if it was only for > those three psuedo platforms, you wouldn't mind. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; hosking at elego.de > Date: Sat, 2 Feb 2008 00:12:27 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > This was deliberate. It enables some cross-build scenarios. That I > admit I haven't used (yet?), but I really like the idea. > If m3linker were completed, then "full" cross builds would be real. > > The "extra" packages are small and build fast (well, at least not > using cm3cg...). > Is it really so onerous? Really? > > Isn't it nice to have less filtering of packages as well? > Like, when you are building on non-NT386, you can easily see that > you didn't break building on NT386, at least partly. > ? > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > To: hosking at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I just checked in support for full declaration of paramters even on > > imported procedures in the gcc-based backend. This is to support > > proper generation of stdcall calling convention on Windows. In the > > process of testing this I discovered that cm3 on non-Windows > > platforms now needs to build and ship both of the Windows x86 > support > > libraries m3back and m3objfile, even though non-Windows platforms > > don't use or need them. This seems broken to me. It seems that cm3 > > has changed so that it now has these dependencies. Can we please > > undo this? -- I see no need to have to build these for non-x86 > > platforms that will never use them. > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > Add parameter decls even for imported procedures, as per Jay > > > Krell's request > > > to support stdcall parameter passing mode on Windows. > > > > > Connect and share in new ways with Windows Live. Get it now! > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From jayk123 at hotmail.com Sat Feb 2 01:45:25 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:45:25 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:22:56 -0500> To: jayk123 at hotmail.com> > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond!> > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > > Actually it's slightly more real than I said.> > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu; hosking at elego.de> > Date: Sat, 2 Feb 2008 00:12:27 +0000> > CC: m3devel at elegosoft.com> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> >> > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea.> > If m3linker were completed, then "full" cross builds would be real.> >> > The "extra" packages are small and build fast (well, at least not > > using cm3cg...).> > Is it really so onerous? Really?> >> > Isn't it nice to have less filtering of packages as well?> > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly.> > ?> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > To: hosking at elego.de> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > >> > > I just checked in support for full declaration of paramters even on> > > imported procedures in the gcc-based backend. This is to support> > > proper generation of stdcall calling convention on Windows. In the> > > process of testing this I discovered that cm3 on non-Windows> > > platforms now needs to build and ship both of the Windows x86 > > support> > > libraries m3back and m3objfile, even though non-Windows platforms> > > don't use or need them. This seems broken to me. It seems that cm3> > > has changed so that it now has these dependencies. Can we please> > > undo this? -- I see no need to have to build these for non-x86> > > platforms that will never use them.> > >> > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > >> > > > CVSROOT: /usr/cvs> > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > >> > > > Modified files:> > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > >> > > > Log message:> > > > Add parameter decls even for imported procedures, as per Jay> > > > Krell's request> > > > to support stdcall parameter passing mode on Windows.> > >> >> >> > Connect and share in new ways with Windows Live. Get it now!> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:56:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:56:18 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> It would be nice to have the x86 integrated backend for I386_LINUX and LINUXLIBC6 too -- just like the old PM3 did. On Feb 1, 2008, at 7:45 PM, Jay wrote: > Hey, I'd kind of like that backend to stay actually. It's quite > fast and generates better code than unoptimized gcc and competitive > code with optimized gcc. There's no AMD64 support anywhere yet in > Modula-3 that I know of. Maybe it will appear here first? :) > > I don't think it is all that gnarly either. But somewhat. It's a > bit like code I've see that is so often handling one case after > another case after yet another case, yet who knows what all the > cases are and which order (if any particular) they should be > handled in? That is, it's actually kind of easier to read it and > understand what it does do, and realize that is "correct" in the > "necessary" sense, but hard to know if it is "sufficient". > I've got outstanding diffs for int64 support I'd like to get back to. > > AMD64 shouldn't be difficult...that's kind of the point, eh? > It's just a slight alteration of x86.. > > Granted, it isn't set up, doesn't have a "framework", to generate > substantially better code. > It doesn't remember much, doesn't make multiple passes, doesn't > have a high level representation, etc. > > In the unlikely event that I succeed, presumably PPC would be > next...:) > > (But yeah yeah, LLVM is probably easier and much more fruitful, > both in terms of platform each and optimization..and hopefully > build speed.) > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > To: jayk123 at hotmail.com > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > that gnarly x86 backend will go away soon anyway -- it's probably > > never going to survive in the x86_64 universe and beyond! > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > Actually it's slightly more real than I said. > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > sense a limited form of cross build. Granted, if it was only for > > > those three psuedo platforms, you wouldn't mind. > > > > > > - Jay > > > > > > From: jayk123 at hotmail.com > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > admit I haven't used (yet?), but I really like the idea. > > > If m3linker were completed, then "full" cross builds would be > real. > > > > > > The "extra" packages are small and build fast (well, at least not > > > using cm3cg...). > > > Is it really so onerous? Really? > > > > > > Isn't it nice to have less filtering of packages as well? > > > Like, when you are building on non-NT386, you can easily see that > > > you didn't break building on NT386, at least partly. > > > ? > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > To: hosking at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > I just checked in support for full declaration of paramters > even on > > > > imported procedures in the gcc-based backend. This is to support > > > > proper generation of stdcall calling convention on Windows. > In the > > > > process of testing this I discovered that cm3 on non-Windows > > > > platforms now needs to build and ship both of the Windows x86 > > > support > > > > libraries m3back and m3objfile, even though non-Windows > platforms > > > > don't use or need them. This seems broken to me. It seems > that cm3 > > > > has changed so that it now has these dependencies. Can we please > > > > undo this? -- I see no need to have to build these for non-x86 > > > > platforms that will never use them. > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > CVSROOT: /usr/cvs > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > Modified files: > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > Log message: > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > Krell's request > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From rcoleburn at scires.com Sat Feb 2 01:57:24 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 19:57:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <47A379A4.1E75.00D7.1@scires.com> I too want to keep that backend. All of my Modula-3 production code in the past was built using it. Regards, Randy >>> Jay 2/1/2008 7:45 PM >>> Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:22:56 -0500 > To: jayk123 at hotmail.com > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond! > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > Actually it's slightly more real than I said. > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu; hosking at elego.de > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea. > > If m3linker were completed, then "full" cross builds would be real. > > > > The "extra" packages are small and build fast (well, at least not > > using cm3cg...). > > Is it really so onerous? Really? > > > > Isn't it nice to have less filtering of packages as well? > > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly. > > ? > > > > - Jay > > > > > > > From: hosking at cs.purdue.edu > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > To: hosking at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > I just checked in support for full declaration of paramters even on > > > imported procedures in the gcc-based backend. This is to support > > > proper generation of stdcall calling convention on Windows. In the > > > process of testing this I discovered that cm3 on non-Windows > > > platforms now needs to build and ship both of the Windows x86 > > support > > > libraries m3back and m3objfile, even though non-Windows platforms > > > don't use or need them. This seems broken to me. It seems that cm3 > > > has changed so that it now has these dependencies. Can we please > > > undo this? -- I see no need to have to build these for non-x86 > > > platforms that will never use them. > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > Modified files: > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > Log message: > > > > Add parameter decls even for imported procedures, as per Jay > > > > Krell's request > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Shed those extra pounds with MSN and The Biggest Loser! Learn more. ( http://biggestloser.msn.com/ ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:02:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:02:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sat Feb 2 02:08:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 20:08:59 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <47A37C5A.1E75.00D7.1@scires.com> Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy >>> Jay 2/1/2008 8:02 PM >>> "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:56:18 -0500 > To: jayk123 at hotmail.com > > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did. > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient". > > I've got outstanding diffs for int64 support I'd like to get back to. > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > It's just a slight alteration of x86.. > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code. > > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc. > > > > In the unlikely event that I succeed, presumably PPC would be > > next...:) > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.) > > > > - Jay > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > To: jayk123 at hotmail.com > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > that gnarly x86 backend will go away soon anyway -- it's probably > > > never going to survive in the x86_64 universe and beyond! > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > Actually it's slightly more real than I said. > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > > sense a limited form of cross build. Granted, if it was only for > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > > admit I haven't used (yet?), but I really like the idea. > > > > If m3linker were completed, then "full" cross builds would be > > real. > > > > > > > > The "extra" packages are small and build fast (well, at least not > > > > using cm3cg...). > > > > Is it really so onerous? Really? > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > Like, when you are building on non-NT386, you can easily see that > > > > you didn't break building on NT386, at least partly. > > > > ? > > > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > To: hosking at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > I just checked in support for full declaration of paramters > > even on > > > > > imported procedures in the gcc-based backend. This is to support > > > > > proper generation of stdcall calling convention on Windows. > > In the > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > platforms now needs to build and ship both of the Windows x86 > > > > support > > > > > libraries m3back and m3objfile, even though non-Windows > > platforms > > > > > don't use or need them. This seems broken to me. It seems > > that cm3 > > > > > has changed so that it now has these dependencies. Can we please > > > > > undo this? -- I see no need to have to build these for non-x86 > > > > > platforms that will never use them. > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > Modified files: > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > Log message: > > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > > Krell's request > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more. > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:19:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:19:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47A37C5A.1E75.00D7.1@scires.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> <47A37C5A.1E75.00D7.1@scires.com> Message-ID: No. (I fully admit I don't know yet what the problem is, and the way the system is designed in my understanding, variations like this are "impossible", therefore throw out nearly all expectations and entertain nearly all ideas, but I don't think this is related. It'll just have to be debugged and code studied and skimmed for hints, and I apologize for the long delay. Maybe some code checks for function equality?? (not sure Modula-3 even supports that, but it's one the small subtleties of dynamic linking that can trip up some unusual slightly sleazy C code)) - Jay Date: Fri, 1 Feb 2008 20:08:59 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; jayk123 at hotmail.comCC: hosking at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy>>> Jay 2/1/2008 8:02 PM >>>"I386_LINUX"? You aren't off renaming platforms now are you Tony? :)Agreed. I stopped looking when I noticed the license..Aha..I guess that is the point of the two "integrated" x86 backends?There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe.The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that...You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 03:23:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 21:23:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <3F43F984-4CF8-4F74-A422-0F129FD00707@cs.purdue.edu> Sorry: I386_DARWIN. On Feb 1, 2008, at 8:02 PM, Jay wrote: > "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) > Agreed. I stopped looking when I noticed the license.. > Aha..I guess that is the point of the two "integrated" x86 backends? > There's just one code base, there there is m3back and > m3staloneback. One builds a .lib, one builds an .exe. > The .exe probably reads the binary file and then replays the > function calls..it's marshaling layer and all that... > You can move the code around to avoid spreading the license and all > that.. > > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:56:18 -0500 > > To: jayk123 at hotmail.com > > > > It would be nice to have the x86 integrated backend for I386_LINUX > > and LINUXLIBC6 too -- just like the old PM3 did. > > > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > > > Hey, I'd kind of like that backend to stay actually. It's quite > > > fast and generates better code than unoptimized gcc and > competitive > > > code with optimized gcc. There's no AMD64 support anywhere yet in > > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > > > I don't think it is all that gnarly either. But somewhat. It's a > > > bit like code I've see that is so often handling one case after > > > another case after yet another case, yet who knows what all the > > > cases are and which order (if any particular) they should be > > > handled in? That is, it's actually kind of easier to read it and > > > understand what it does do, and realize that is "correct" in the > > > "necessary" sense, but hard to know if it is "sufficient". > > > I've got outstanding diffs for int64 support I'd like to get > back to. > > > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > > It's just a slight alteration of x86.. > > > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > > substantially better code. > > > It doesn't remember much, doesn't make multiple passes, doesn't > > > have a high level representation, etc. > > > > > > In the unlikely event that I succeed, presumably PPC would be > > > next...:) > > > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > > both in terms of platform each and optimization..and hopefully > > > build speed.) > > > > > > - Jay > > > > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > > that gnarly x86 backend will go away soon anyway -- it's > probably > > > > never going to survive in the x86_64 universe and beyond! > > > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > > > Actually it's slightly more real than I said. > > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/ > NT386MINGNU. > > > > > Sometimes it uses the "extra" code, sometimes not. These > are in a > > > > > sense a limited form of cross build. Granted, if it was > only for > > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > > > - Jay > > > > > > > > > > From: jayk123 at hotmail.com > > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > This was deliberate. It enables some cross-build scenarios. > That I > > > > > admit I haven't used (yet?), but I really like the idea. > > > > > If m3linker were completed, then "full" cross builds would be > > > real. > > > > > > > > > > The "extra" packages are small and build fast (well, at > least not > > > > > using cm3cg...). > > > > > Is it really so onerous? Really? > > > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > > Like, when you are building on non-NT386, you can easily > see that > > > > > you didn't break building on NT386, at least partly. > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > > To: hosking at elego.de > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > > > I just checked in support for full declaration of paramters > > > even on > > > > > > imported procedures in the gcc-based backend. This is to > support > > > > > > proper generation of stdcall calling convention on Windows. > > > In the > > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > > platforms now needs to build and ship both of the Windows > x86 > > > > > support > > > > > > libraries m3back and m3objfile, even though non-Windows > > > platforms > > > > > > don't use or need them. This seems broken to me. It seems > > > that cm3 > > > > > > has changed so that it now has these dependencies. Can we > please > > > > > > undo this? -- I see no need to have to build these for > non-x86 > > > > > > platforms that will never use them. > > > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > > > Modified files: > > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > > > Log message: > > > > > > > Add parameter decls even for imported procedures, as > per Jay > > > > > > > Krell's request > > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > > more. > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 07:23:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 06:23:09 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <20080204054529.A4C4F10D4611@birch.elegosoft.com> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: (and codegen..) C:\dev2\j\m3\t>type t.c typedef struct { int a,b,c,d,e,f;} Foo_t; void __stdcall Sleep(Foo_t foo); extern Foo_t a; void F1(){ Sleep(a);} C:\dev2\j\m3\t>gcc -c -S t.c C:\dev2\j\m3\t>type t.s .file "t.c" .text.globl _F1 .def _F1; .scl 2; .type 32; .endef_F1: pushl %ebp movl %esp, %ebp subl $24, %esp movl _a, %eax movl %eax, (%esp) movl _a+4, %eax movl %eax, 4(%esp) movl _a+8, %eax movl %eax, 8(%esp) movl _a+12, %eax movl %eax, 12(%esp) movl _a+16, %eax movl %eax, 16(%esp) movl _a+20, %eax movl %eax, 20(%esp) call _Sleep at 24 subl $24, %esp leave ret C:\dev2\j\m3\t>(NOTE: This is NOT the correct declaration of Sleep, but ok for testing purposes.) C:\dev2\j\m3\t>type t.i3INTERFACE T; TYPE Foo_t = RECORD a,b,c,d,e,f : INTEGER;END; <*EXTERNAL Sleep:WINAPI*>PROCEDURE Sleep (dwMilliseconds1: Foo_t); END T. C:\dev2\j\m3\t>type t.m3 MODULE T; VAR Foo: Foo_t; BEGIN Sleep(Foo);END T. LM1: movl 8(%ebp), %eax xorl $1, %eax testb %al, %al jne L2 .stabn 68,0,6,LM2-_T_M3LM2: movl $_MM_T+52, %eax movl %eax, %edx subl $8, %esp subl $24, %esp movl %esp, %eax movl %eax, %edi movl %edx, %esi cld movl $6, %eax movl %eax, %ecx rep movsl call _Sleep at 4 addl $8, %espL2: movl $_MM_T, %eaxLBE2: leal -8(%ebp), %esp popl %esi popl %edi leave ret ? - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 15:52:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 09:52:31 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: Any chance that standard_structs in Target.i3 is causing the front- end to pass structs by reference (standard structs=TRUE)? Also, looking at pop_struct in parse.c it seems to want to pass them by reference (standard_structs=FALSE)? In any case, what does the integrated back-end do with pop_struct? I bet it is passing by value... whereas parse.c passes by ref. Blurgh! Looks like we need to smarten things up for calls to non-M3 stdcall procedures. On Feb 4, 2008, at 1:23 AM, Jay wrote: > (and codegen..) > > C:\dev2\j\m3\t>type t.c > > typedef struct { > int a,b,c,d,e,f; > } Foo_t; > > void __stdcall Sleep(Foo_t foo); > > extern Foo_t a; > > void F1() > { > Sleep(a); > } > > C:\dev2\j\m3\t>gcc -c -S t.c > > C:\dev2\j\m3\t>type t.s > .file "t.c" > .text > .globl _F1 > .def _F1; .scl 2; .type 32; .endef > _F1: > pushl %ebp > movl %esp, %ebp > subl $24, %esp > movl _a, %eax > movl %eax, (%esp) > movl _a+4, %eax > movl %eax, 4(%esp) > movl _a+8, %eax > movl %eax, 8(%esp) > movl _a+12, %eax > movl %eax, 12(%esp) > movl _a+16, %eax > movl %eax, 16(%esp) > movl _a+20, %eax > movl %eax, 20(%esp) > call _Sleep at 24 > subl $24, %esp > leave > ret > C:\dev2\j\m3\t> > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > testing purposes.) > > C:\dev2\j\m3\t>type t.i3 > INTERFACE T; > > TYPE Foo_t = RECORD > a,b,c,d,e,f : INTEGER; > END; > > <*EXTERNAL Sleep:WINAPI*> > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > END T. > > C:\dev2\j\m3\t>type t.m3 > > MODULE T; > VAR > Foo: Foo_t; > > BEGIN > Sleep(Foo); > END T. > > > LM1: > movl 8(%ebp), %eax > xorl $1, %eax > testb %al, %al > jne L2 > .stabn 68,0,6,LM2-_T_M3 > LM2: > movl $_MM_T+52, %eax > movl %eax, %edx > subl $8, %esp > subl $24, %esp > movl %esp, %eax > movl %eax, %edi > movl %edx, %esi > cld > movl $6, %eax > movl %eax, %ecx > rep > movsl > call _Sleep at 4 > addl $8, %esp > L2: > movl $_MM_T, %eax > LBE2: > leal -8(%ebp), %esp > popl %esi > popl %edi > leave > ret > > ? > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 20:43:43 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:43:43 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I think they are being passed correctly, by value. pop_struct and not pop_param is used. When I get time, I will put my parse.c back (uncommited) and then just try some tests with "__cdecl" passing and returning structs. That removes the naming issue and PART of the calling convention issue and tests what is left. Then I'll see if I can hack something up to test the rest. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 20:46:00 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:46:00 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures. ps: m3 or not m3 I would think. stdcall is stdcall, independent of the implementing language. Though sure, the C declaration could declare the thing by const pointer. Given some existing unchanged C declarations for "callbacks" however, I should be able to implement them in M3. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 21:30:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:23 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> OK. Not sure I understand what is going on then -- I would like to see the .mc file to get a sense of things. On Feb 4, 2008, at 2:43 PM, Jay wrote: > I think they are being passed correctly, by value. pop_struct and > not pop_param is used. > When I get time, I will put my parse.c back (uncommited) and then > just try some tests with "__cdecl" passing and returning structs. > That removes the naming issue and PART of the calling convention > issue and tests what is left. > Then I'll see if I can hack something up to test the rest. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From hosking at cs.purdue.edu Mon Feb 4 21:30:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:59 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I don't think I follow you. On Feb 4, 2008, at 2:46 PM, Jay wrote: > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > the implementing language. > Though sure, the C declaration could declare the thing by const > pointer. > > Given some existing unchanged C declarations for "callbacks" > however, I should be able to implement them in M3. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From jayk123 at hotmail.com Mon Feb 4 21:38:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:38:28 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > > > to smarten things up for calls to non-M3 stdcall procedures. Why is the smartening specific to non-M3 procedures?I should be able to write stdcall functions in M3 as well, that take and return structs, I am so inclined or "forced". (Arguably, it should be the default. It is slightly more efficient.) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:59 -0500> To: jayk123 at hotmail.com> > I don't think I follow you.> > On Feb 4, 2008, at 2:46 PM, Jay wrote:> > > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> >> > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > the implementing language.> > Though sure, the C declaration could declare the thing by const > > pointer.> >> > Given some existing unchanged C declarations for "callbacks" > > however, I should be able to implement them in M3.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 21:51:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:51:01 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working. m3quake => sysutils => libm3/TextExtras but TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do. I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 22:01:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:01:44 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: This is without your most recent changes. > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:23 -0500> To: jayk123 at hotmail.com> > OK. Not sure I understand what is going on then -- I would like to > see the .mc file to get a sense of things.> > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > > I think they are being passed correctly, by value. pop_struct and > > not pop_param is used.> > When I get time, I will put my parse.c back (uncommited) and then > > just try some tests with "__cdecl" passing and returning structs. > > That removes the naming issue and PART of the calling convention > > issue and tests what is left.> > Then I'll see if I can hack something up to test the rest.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:05:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:05:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <927CD38A-8DA0-4963-83D4-265C9098BDCC@cs.purdue.edu> I agree. I was suspicious of the standard_structs flag -- you probably know better than I do what it is supposed to do. On Feb 4, 2008, at 3:38 PM, Jay wrote: > > > > to smarten things up for calls to non-M3 stdcall procedures. > > Why is the smartening specific to non-M3 procedures? > I should be able to write stdcall functions in M3 as well, that > take and return structs, I am so inclined or "forced". > (Arguably, it should be the default. It is slightly more efficient.) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:59 -0500 > > To: jayk123 at hotmail.com > > > > I don't think I follow you. > > > > On Feb 4, 2008, at 2:46 PM, Jay wrote: > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > > the implementing language. > > > Though sure, the C declaration could declare the thing by const > > > pointer. > > > > > > Given some existing unchanged C declarations for "callbacks" > > > however, I should be able to implement them in M3. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 4 22:09:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:09:50 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: 5.1.8 worked From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: bootstrapping from old versions?Date: Mon, 4 Feb 2008 20:51:01 +0000 It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working.m3quake => sysutils => libm3/TextExtrasbut TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do.I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 22:19:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:19:38 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: Jay, I'm not on Windows so I can't diagnose the stdcall problem. I want to see the .mc file so I can get a sense of what is going on. On Feb 4, 2008, at 4:01 PM, Jay wrote: > This is without your most recent changes. > > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > To: jayk123 at hotmail.com > > > > OK. Not sure I understand what is going on then -- I would like to > > see the .mc file to get a sense of things. > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > I think they are being passed correctly, by value. pop_struct and > > > not pop_param is used. > > > When I get time, I will put my parse.c back (uncommited) and then > > > just try some tests with "__cdecl" passing and returning structs. > > > That removes the naming issue and PART of the calling convention > > > issue and tests what is left. > > > Then I'll see if I can hack something up to test the rest. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Connect and share in new ways with Windows Live. Get it now! > From jayk123 at hotmail.com Mon Feb 4 22:28:49 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:28:49 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: understood, did the attachment not come through? attached again (parse.c changes aren't really relevant here anyway, not for the *c files, but for the *s files) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 16:19:38 -0500> To: jayk123 at hotmail.com> > Jay,> > I'm not on Windows so I can't diagnose the stdcall problem. I want > to see the .mc file so I can get a sense of what is going on.> > On Feb 4, 2008, at 4:01 PM, Jay wrote:> > > This is without your most recent changes.> >> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 15:30:23 -0500> > > To: jayk123 at hotmail.com> > >> > > OK. Not sure I understand what is going on then -- I would like to> > > see the .mc file to get a sense of things.> > >> > > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > >> > > > I think they are being passed correctly, by value. pop_struct and> > > > not pop_param is used.> > > > When I get time, I will put my parse.c back (uncommited) and then> > > > just try some tests with "__cdecl" passing and returning structs.> > > > That removes the naming issue and PART of the calling convention> > > > issue and tests what is left.> > > > Then I'll see if I can hack something up to test the rest.> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: stdcall naming discrepancy?> > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > > Any chance that standard_structs in Target.i3 is causing the > > front-> > > > > end to pass structs by reference (standard structs=TRUE)? Also,> > > > > looking at pop_struct in parse.c it seems to want to pass > > them by> > > > > reference (standard_structs=FALSE)? In any case, what does the> > > > > integrated back-end do with pop_struct? I bet it is passing by> > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > > need> > > > > to smarten things up for calls to non-M3 stdcall procedures.> > > > >> > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > > >> > > > > > (and codegen..)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.c> > > > > >> > > > > > typedef struct {> > > > > > int a,b,c,d,e,f;> > > > > > } Foo_t;> > > > > >> > > > > > void __stdcall Sleep(Foo_t foo);> > > > > >> > > > > > extern Foo_t a;> > > > > >> > > > > > void F1()> > > > > > {> > > > > > Sleep(a);> > > > > > }> > > > > >> > > > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > > > >> > > > > > C:\dev2\j\m3\t>type t.s> > > > > > .file "t.c"> > > > > > .text> > > > > > .globl _F1> > > > > > .def _F1; .scl 2; .type 32; .endef> > > > > > _F1:> > > > > > pushl %ebp> > > > > > movl %esp, %ebp> > > > > > subl $24, %esp> > > > > > movl _a, %eax> > > > > > movl %eax, (%esp)> > > > > > movl _a+4, %eax> > > > > > movl %eax, 4(%esp)> > > > > > movl _a+8, %eax> > > > > > movl %eax, 8(%esp)> > > > > > movl _a+12, %eax> > > > > > movl %eax, 12(%esp)> > > > > > movl _a+16, %eax> > > > > > movl %eax, 16(%esp)> > > > > > movl _a+20, %eax> > > > > > movl %eax, 20(%esp)> > > > > > call _Sleep at 24> > > > > > subl $24, %esp> > > > > > leave> > > > > > ret> > > > > > C:\dev2\j\m3\t>> > > > > >> > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > > for> > > > > > testing purposes.)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.i3> > > > > > INTERFACE T;> > > > > >> > > > > > TYPE Foo_t = RECORD> > > > > > a,b,c,d,e,f : INTEGER;> > > > > > END;> > > > > >> > > > > > <*EXTERNAL Sleep:WINAPI*>> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > > > END T.> > > > > >> > > > > > C:\dev2\j\m3\t>type t.m3> > > > > >> > > > > > MODULE T;> > > > > > VAR> > > > > > Foo: Foo_t;> > > > > >> > > > > > BEGIN> > > > > > Sleep(Foo);> > > > > > END T.> > > > > >> > > > > >> > > > > > LM1:> > > > > > movl 8(%ebp), %eax> > > > > > xorl $1, %eax> > > > > > testb %al, %al> > > > > > jne L2> > > > > > .stabn 68,0,6,LM2-_T_M3> > > > > > LM2:> > > > > > movl $_MM_T+52, %eax> > > > > > movl %eax, %edx> > > > > > subl $8, %esp> > > > > > subl $24, %esp> > > > > > movl %esp, %eax> > > > > > movl %eax, %edi> > > > > > movl %edx, %esi> > > > > > cld> > > > > > movl $6, %eax> > > > > > movl %eax, %ecx> > > > > > rep> > > > > > movsl> > > > > > call _Sleep at 4> > > > > > addl $8, %esp> > > > > > L2:> > > > > > movl $_MM_T, %eax> > > > > > LBE2:> > > > > > leal -8(%ebp), %esp> > > > > > popl %esi> > > > > > popl %edi> > > > > > leave> > > > > > ret> > > > > >> > > > > > ?> > > > > >> > > > > > - Jay> > > > > >> > > > > > Connect and share in new ways with Windows Live. Get it now!> > > > >> > > >> > > >> > > > Climb to the top of the charts! Play the word scramble challenge> > > > with star power. Play now!> > >> >> >> > Connect and share in new ways with Windows Live. Get it now! > > > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:59:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:59:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: I just checked in a fix that initializes void_list_node. I think this may be the fix you need for stdargs. As far as I know, void_list_node is used to mark the end of non-varargs parameter lists. On Feb 4, 2008, at 4:28 PM, Jay wrote: > understood, did the attachment not come through? > attached again > (parse.c changes aren't really relevant here anyway, not for the *c > files, but for the *s files) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 16:19:38 -0500 > > To: jayk123 at hotmail.com > > > > Jay, > > > > I'm not on Windows so I can't diagnose the stdcall problem. I want > > to see the .mc file so I can get a sense of what is going on. > > > > On Feb 4, 2008, at 4:01 PM, Jay wrote: > > > > > This is without your most recent changes. > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > OK. Not sure I understand what is going on then -- I would > like to > > > > see the .mc file to get a sense of things. > > > > > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > > > > > I think they are being passed correctly, by value. > pop_struct and > > > > > not pop_param is used. > > > > > When I get time, I will put my parse.c back (uncommited) > and then > > > > > just try some tests with "__cdecl" passing and returning > structs. > > > > > That removes the naming issue and PART of the calling > convention > > > > > issue and tests what is left. > > > > > Then I'll see if I can hack something up to test the rest. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: stdcall naming discrepancy? > > > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > > > front- > > > > > > end to pass structs by reference (standard structs=TRUE)? > Also, > > > > > > looking at pop_struct in parse.c it seems to want to pass > > > them by > > > > > > reference (standard_structs=FALSE)? In any case, what > does the > > > > > > integrated back-end do with pop_struct? I bet it is > passing by > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks > like we > > > need > > > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > > > > > (and codegen..) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > > > > > typedef struct { > > > > > > > int a,b,c,d,e,f; > > > > > > > } Foo_t; > > > > > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > > > > > extern Foo_t a; > > > > > > > > > > > > > > void F1() > > > > > > > { > > > > > > > Sleep(a); > > > > > > > } > > > > > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > > > .file "t.c" > > > > > > > .text > > > > > > > .globl _F1 > > > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > > > _F1: > > > > > > > pushl %ebp > > > > > > > movl %esp, %ebp > > > > > > > subl $24, %esp > > > > > > > movl _a, %eax > > > > > > > movl %eax, (%esp) > > > > > > > movl _a+4, %eax > > > > > > > movl %eax, 4(%esp) > > > > > > > movl _a+8, %eax > > > > > > > movl %eax, 8(%esp) > > > > > > > movl _a+12, %eax > > > > > > > movl %eax, 12(%esp) > > > > > > > movl _a+16, %eax > > > > > > > movl %eax, 16(%esp) > > > > > > > movl _a+20, %eax > > > > > > > movl %eax, 20(%esp) > > > > > > > call _Sleep at 24 > > > > > > > subl $24, %esp > > > > > > > leave > > > > > > > ret > > > > > > > C:\dev2\j\m3\t> > > > > > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, > but ok > > > for > > > > > > > testing purposes.) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > > > INTERFACE T; > > > > > > > > > > > > > > TYPE Foo_t = RECORD > > > > > > > a,b,c,d,e,f : INTEGER; > > > > > > > END; > > > > > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > > > END T. > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > > > > > MODULE T; > > > > > > > VAR > > > > > > > Foo: Foo_t; > > > > > > > > > > > > > > BEGIN > > > > > > > Sleep(Foo); > > > > > > > END T. > > > > > > > > > > > > > > > > > > > > > LM1: > > > > > > > movl 8(%ebp), %eax > > > > > > > xorl $1, %eax > > > > > > > testb %al, %al > > > > > > > jne L2 > > > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > > > LM2: > > > > > > > movl $_MM_T+52, %eax > > > > > > > movl %eax, %edx > > > > > > > subl $8, %esp > > > > > > > subl $24, %esp > > > > > > > movl %esp, %eax > > > > > > > movl %eax, %edi > > > > > > > movl %edx, %esi > > > > > > > cld > > > > > > > movl $6, %eax > > > > > > > movl %eax, %ecx > > > > > > > rep > > > > > > > movsl > > > > > > > call _Sleep at 4 > > > > > > > addl $8, %esp > > > > > > > L2: > > > > > > > movl $_MM_T, %eax > > > > > > > LBE2: > > > > > > > leal -8(%ebp), %esp > > > > > > > popl %esi > > > > > > > popl %edi > > > > > > > leave > > > > > > > ret > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it > now! > > > > > > > > > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble > challenge > > > > > with star power. Play now! > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 4 23:14:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 17:14:16 -0500 Subject: [M3devel] Latest parse.c Message-ID: See this snip from gcc/gcc/config/winnt.c: > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl)); > if (formal_type != NULL_TREE) > { > /* These attributes are ignored for variadic functions in > i386.c:ix86_return_pops_args. For compatibility with MS > compiler do not add @0 suffix here. */ > if (TREE_VALUE (tree_last (formal_type)) != void_type_node) > return DECL_ASSEMBLER_NAME (decl); We need a void_type_node there -- void_list_node now captures that properly. > /* Quit if we hit an incomplete type. Error is reported > by convert_arguments in c-typeck.c or cp/typeck.c. */ I wonder if the remaining problem with the wrong @N value is because we don't have a complete type on the formals? > while (TREE_VALUE (formal_type) != void_type_node > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > { > int parm_size > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type))); > /* Must round up to include padding. This is done the same > way as in store_one_arg. */ > parm_size = ((parm_size + PARM_BOUNDARY - 1) > / PARM_BOUNDARY * PARM_BOUNDARY); > total += parm_size; > formal_type = TREE_CHAIN (formal_type);\ > } > } From jayk123 at hotmail.com Mon Feb 4 23:25:52 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 22:25:52 +0000 Subject: [M3devel] Latest parse.c In-Reply-To: References: Message-ID: I'll try later. I tried stepping through some of this in gdb but couldn't make much sense of the data. Perhaps due to optimization. And I read some of it, but didn't really notice what you point out, thanks. I need to be more willing to resort to printf debugging..it worked well with those aligned doubles.. It should help (any of us) to use that small repro I provided. I don't think it "quits" for us, but worth the printf'ing and such. It does append "@4" to Sleep. Another thing would be try: like Sleep(int,record,int,record); I wouldn't be surprised if you get @16, but I'm placing no bets here. :) I should also try building some cross m3cg's so I can nag you to do the same. :) (if it only it were that easy, also need cross gcc, ld, headers, libs, and then could build all distributions from one machine, albeit NT386 is the real laggard here...) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Latest parse.c> Date: Mon, 4 Feb 2008 17:14:16 -0500> To: jayk123 at hotmail.com> > See this snip from gcc/gcc/config/winnt.c:> > > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl));> > if (formal_type != NULL_TREE)> > {> > /* These attributes are ignored for variadic functions in> > i386.c:ix86_return_pops_args. For compatibility with MS> > compiler do not add @0 suffix here. */> > if (TREE_VALUE (tree_last (formal_type)) != void_type_node)> > return DECL_ASSEMBLER_NAME (decl);> > We need a void_type_node there -- void_list_node now captures that > properly.> > > /* Quit if we hit an incomplete type. Error is reported> > by convert_arguments in c-typeck.c or cp/typeck.c. */> > I wonder if the remaining problem with the wrong @N value is because > we don't have a complete type on the formals?> > > while (TREE_VALUE (formal_type) != void_type_node> > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > > {> > int parm_size> > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type)));> > /* Must round up to include padding. This is done the same> > way as in store_one_arg. */> > parm_size = ((parm_size + PARM_BOUNDARY - 1)> > / PARM_BOUNDARY * PARM_BOUNDARY);> > total += parm_size;> > formal_type = TREE_CHAIN (formal_type);\> > }> > }> > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 5 10:36:55 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 5 Feb 2008 09:36:55 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801291036.m0TAaVws062299@camembert.async.caltech.edu> References: Your message of "Mon, 28 Jan 2008 12:38:38 GMT." <200801291036.m0TAaVws062299@camembert.async.caltech.edu> Message-ID: Mika you are right, e.g.: C:\pm3\bin>mentor.exe ****** runtime error:*** ThreadWin32.m3, line 726: Windows OS failure, GetLastError = 8*** use option @M3stackdump to get a stack trace 20754 [unknown (0xF84)] mentor 2780 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 42083 [unknown (0xF84)] mentor 2780 open_stackdumpfile: Dumping stack trace to mentor.exe.stackdump And it uses Win32 gui. I am still inclined to use pthreads though.. - Jay > To: jayk123 at hotmail.com> Subject: Re: [M3devel] nt386gnu threads? > Date: Tue, 29 Jan 2008 02:36:31 -0800> From: mika at async.caltech.edu> > > Sorry, I don't have the m3makefiles. I just have a binary installation> of PM3/Klagenfurt.> > Practice your German:> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > here...> > http://www.1o0.de/wi-links/modula3/> > (Sorry I don't even have access to my Windows system right now.)> > Mika> > Jay writes:> >--_14fad708-4bac-4aaf-ab93-c9649038a920_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Um, so the file exists..does it get compiled? Did you look at the m3makefil=> >es?> >I skimmed the m3makefiles. I have not tried building PM3 myself.> >=20> > - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Feb 5 12:15:44 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 5 Feb 2008 12:15:44 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Message-ID: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Hi Olaf: Is still possible to add Literate programming support, I mean using several functions that are just a commentary at the end of the file on M3Build.m3: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain Also there is a missing one on Built-in functions, one that "copy" the derived source of a noweb file (specifically a generic) from the Target (e.g LINUXLIBC6) directory of the compiler to the src directory. In that way the compiler can use the source. The name of functions could be: "derived_generic_interface", "derived_generic_implementation" This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ The literate programming support was present on DEC SRC M3 I think: http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Thanks Daniel Benavides Olaf Wagner escribi?: Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 5 12:39:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 05 Feb 2008 12:39:23 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080205123923.qvlr4noeocgkc8gs@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain You're talking of the builder's built-in functions; I haven't had a close look at them yet (just extended the pure quake built-ins). Of course it should be possible to add support for literate programming; but I haven't any experience with this. > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. I don't think it should be done this way, and it wouldn't really work, as the compiler would need two passes for each package then; all derived files should be kept in the TARGET directory. I think derived sources for literate programming should be handled in the same way as instantiated generics (e.g. based on quake templates). > In that way the compiler can use the source. The name of functions > could be: "derived_generic_interface", > "derived_generic_implementation" The actual implementation could be done in quake first and maybe later be implemented in M3 in the builder for performance reasons. > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html As I said, I've never used it and don't know about it, but will have a look at it when I've got some time. If you could provide some of the needed quake functions, that would of course 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 Wed Feb 6 20:15:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 06 Feb 2008 20:15:26 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 6 22:46:31 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 6 Feb 2008 21:46:31 +0000 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: Modula-3 and quake both support writing comments already. :) I guess a "cross referencing" scheme would be nice, but to some extent that should be automatic. To some extent, or entirely, it is what Reactor is. All the calls to a function or references to a type are immediately findable, I think. All you really need is a) a completely global namespace so every identifier is unique b) plain text search based on an index. I like C++ and I like some about Modula-3, but hierarchical namespaces really stink in the face of (indexed) plain text search, and no other kind of search can keep up with large codebases. How do I find uses of this particular "T" when people can and do make aliases? I realize C has typedefs to establish aliases, and nesting, so that argument is somewhat moot (the point is more relevant for C++, trying to make it Modula-3-relevant). In C++, how do I search for calls to a particular operator=? Or to a constructor? I'm just being obnoxious. ...Jay > Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dabenavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." :> > > Hi Olaf:> > Is still possible to add Literate programming support, I mean using > > several functions that are just a commentary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain> >> > Also there is a missing one on Built-in functions, one that "copy" > > the derived source of a noweb file (specifically a generic) from the > > Target (e.g LINUXLIBC6) directory of the compiler to the src > > directory. In that way the compiler can use the source. The name of > > functions could be: "derived_generic_interface", > > "derived_generic_implementation"> >> > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/> > The literate programming support was present on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a look at all that stuff, even downloaded ldb and installed noweb.> Still, I'd need a simple example to understand what exactly you would> like to have included in CM3 by default. Just the four commented-out> noweb procedures from M3Build.m3? Or more elaborate stuff like that> included in the ldb distribution?> > Is there any problem with just including the 4 quake procedures as> template? Anything that would not work?> > If you could provide a simple m3 package which contains all the uses> you'd like to see supported, we could even use that as a regression> test add-on. So if you send me a more specific and exact definition> and example, I'll try to add everything that is needed.> > I've never done literate programming myself, and haven't got the time> to learn everything now and decide what is needed.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Feb 6 23:04:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 06 Feb 2008 14:04:43 -0800 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: Your message of "Wed, 06 Feb 2008 21:46:31 GMT." Message-ID: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Isn't Nelson's book "Systems Programming with Modula-3" to a large extent composed of literate programming (Threads interfaces, etc.)? Modula-3 has really cool literate programming support and it'd be a shame to lose it. Also m3browser does support the automatic cross referencing you're talking about. Last I checked it was a bit buggy. In my experience, one of the really nice things about Modula-3 when you write moderately large programs is actually that it's very easy to find out where a T is being used, without using any special tools (like m3browser). You just grep for the name of the interface where that T is defined, and that gives you a superset of all possible uses of T. Modula-3 doesn't have the nasty Javaism "import libm3.*;" Mika Jay writes: >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Modula-3 and quake both support writing comments already. :) >=20 >I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic. >To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think. >=20 >All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index. >=20 >I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor? >=20 >I'm just being obnoxious. >=20 > ...Jay > > > >> Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dab= >enavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake= > extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." enavidesd at yahoo.es>:> > > Hi Olaf:> > Is still possible to add Literate pro= >gramming support, I mean using > > several functions that are just a commen= >tary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.= >com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=3D1.8;c= >ontent-type=3Dtext%2Fplain> >> > Also there is a missing one on Built-in fu= >nctions, one that "copy" > > the derived source of a noweb file (specifical= >ly a generic) from the > > Target (e.g LINUXLIBC6) directory of the compile= >r to the src > > directory. In that way the compiler can use the source. Th= >e name of > > functions could be: "derived_generic_interface", > > "derived= >_generic_implementation"> >> > This stuff is used on ldb debugger : http://= >www.eecs.harvard.edu/nr/ldb/> > The literate programming support was presen= >t on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS= >/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a = >look at all that stuff, even downloaded ldb and installed noweb.> Still, I'= >d need a simple example to understand what exactly you would> like to have = >included in CM3 by default. Just the four commented-out> noweb procedures f= >rom M3Build.m3? Or more elaborate stuff like that> included in the ldb dist= >ribution?> > Is there any problem with just including the 4 quake procedure= >s as> template? Anything that would not work?> > If you could provide a sim= >ple m3 package which contains all the uses> you'd like to see supported, we= > could even use that as a regression> test add-on. So if you send me a more= > specific and exact definition> and example, I'll try to add everything tha= >t is needed.> > I've never done literate programming myself, and haven't go= >t the time> to learn everything now and decide what is needed.> > Olaf> -- = >> Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb= >=E4ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177= > 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf= >=FChrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlotten= >burg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Modula-3 and quake both support writing comments = >already. :)
> 
>I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic.
>To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think.
> 
>All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index.
> 
>I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor?
> 
>I'm just being obnoxious.
> 
> ...Jay


> >
>
>> Date: Wed, 6 Feb 2008 20:15:26 +0100
> From: wagner at elegosoft.co= >m
> To: dabenavidesd at yahoo.es
> CC: m3devel at elegosoft.com
&g= >t; Subject: Re: [M3devel] quake extensions for tests / RFC
>
>= > Quoting "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>:
= >>
> > Hi Olaf:
> > Is still possible to add Literate = >programming support, I mean using
> > several functions that are = >just a commentary at the end of the file
> > on M3Build.m3:
&g= >t; > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-s= >ys/cm3/src/M3Build.m3?rev=3D1.8;content-type=3Dtext%2Fplain
> >>> > Also there is a missing one on Built-in functions, one that "cop= >y"
> > the derived source of a noweb file (specifically a generic= >) from the
> > Target (e.g LINUXLIBC6) directory of the compiler = >to the src
> > directory. In that way the compiler can use the so= >urce. The name of
> > functions could be: "derived_generic_interf= >ace",
> > "derived_generic_implementation"
> >
> &= >gt; This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb= >/
> > The literate programming support was present on DEC SRC M3 I= > think:
> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA= >_3/html/modula-3/html/m3build/noweb.html
>
> Hi again,
>= >
> I've had a look at all that stuff, even downloaded ldb and instal= >led noweb.
> Still, I'd need a simple example to understand what exac= >tly you would
> like to have included in CM3 by default. Just the fou= >r commented-out
> noweb procedures from M3Build.m3? Or more elaborate= > stuff like that
> included in the ldb distribution?
>
>= > Is there any problem with just including the 4 quake procedures as
>= > template? Anything that would not work?
>
> If you could prov= >ide a simple m3 package which contains all the uses
> you'd like to s= >ee supported, we could even use that as a regression
> test add-on. S= >o if you send me a more specific and exact definition
> and example, = >I'll try to add everything that is needed.
>
> I've never done= > literate programming myself, and haven't got the time
> to learn eve= >rything now and decide what is needed.
>
> Olaf
> -- >> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-All= >ee 25 / Geb=E4ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 = >96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.eleg= >osoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelr= >egister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
&g= >t;


Connect and share in new ways with Windows Live. href=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharel= >ife_012008' target=3D'_new'>Get it now! >= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_-- From wagner at elegosoft.com Thu Feb 7 00:07:08 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 07 Feb 2008 00:07:08 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> References: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Message-ID: <20080207000708.380w844gg80cws0k@mail.elegosoft.com> Quoting Mika Nystrom : > Isn't Nelson's book "Systems Programming with Modula-3" to a large > extent composed of literate programming (Threads interfaces, etc.)? > Modula-3 has really cool literate programming support and it'd be > a shame to lose it. Also m3browser does support the automatic cross > referencing you're talking about. Last I checked it was a bit > buggy. Well, I think you're right and one can see m3browser as a kind of special literate programming support. And if it is currently buggy -- perhaps you could explain what exactly is wrong -- we should certainly fix it. However, I understood the request of Daniel Alejandro Benavides as one to re-add support for some generic literate programming tools which where already supported in earlier releases of M3. There is no harm in that, and I think we should be open for integrations of many such tools. I don't think it will be very difficult to add this support (as it has already been there), I'm just not familiar enough with the noweb tools to exactly know what is needed, so I asked for some help. I also think the SGML tools that were used for the PM3 documentation are a kind of literate programming support; and that's probably the most powerful and promising solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Feb 7 03:30:49 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 Feb 2008 03:30:49 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Feb 8 21:49:19 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 8 Feb 2008 21:49:19 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Message-ID: <32680.74034.qm@web27114.mail.ukl.yahoo.com> Hi: I'm sorry for not writing you all the things I like to see on CM3. It seems that the creator of ldb (Norman Ramsey) has been the creator of noweb, so I think his package as far as I have compiled it, is a good test, but maybe too large, so yes I would love to contribute with it. >Is there any problem with just including the 4 quake procedures as >template? Anything that would not work? There isn`t (I think I have compiled with those functions as a ldb-template package template on ldb), but the builtin procedure which I don't see is the one I wrote so I think it should be added in this text case of ldb but also in other cases (I think quake acts as a prepocessor of the noweb Modula-3/generic sources). Thanks again, and hope that I answeres better this time. "Daniel Alejandro Benavides D." escribi?: Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 9 18:52:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 09 Feb 2008 18:52:43 +0100 Subject: [M3devel] www.opencm3.net, m3tohtml and current CM3 source browser Message-ID: <20080209185243.kbm6grheyoks40g0@mail.elegosoft.com> After looking for some suitable domain names that are still available, Elego has secured www.opencm3.net to allow easier access to the CM3 project. http://www.opemcm3.net is now the same as http://modula3.elegosoft.com/cm3/ but shorter and probably easier to remember. Unfortunately www.opencm3.org and the shorter www.cm3.xxx domains are already owned by others. I've made a small update to m3tohtml and automated the HTML doc generation in cm3/scripts/regression/defs.sh:test_m3tohtml. This is now also run nightly on birch.elegosoft.com. Next to running m3browser directly on our web server, this seems the easiest way to allow browsing of all current sources. Have a look at http://www.opencm3.net/doc/help/gen_html/INDEX.html. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 10 10:28:22 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:28:22 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: "cross posting", guilty. (This might have something to do with NT386GNU CM3 hanging upon startup but I haven't figured out much..in CM3, nanosleep fails and I don't think ThreadPThread__SignalHandler is ever called, whereas here nanosleep succeeds and the signal handler is called at least a few times; I'm going to try some hack with the Cygwin nanosleep uses sleep instead or something...) From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 10 10:43:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:43:58 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: oh the burden of my own cross-posting.. - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: RE: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:43:20 +0000 Given that sleep is implemented via nanosleep in the obvious simple way..Still, any additional clues/explanations are welcome. :) - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sun Feb 10 22:55:01 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 10 Feb 2008 15:55:01 -0600 Subject: [M3devel] <*LAZYALIGN*> Message-ID: <47AF72B5.2080308@wichita.edu> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it being used anywhere? It is not documented in pragmas.html. The compiler front end appears to accept it. (In fact, Decls.m3 contains constants that suggest limitations on what declarations the pragma can appear on, but these are not actually enforced.) It liberalizes the alignment rules, generally allowing scalars to start on any byte boundary. Pickles have to be able to reconstruct the layout of types as the compiler would have done it for a machine (on which a now-being-read pickle was written) with different word size and alignment properties. Currently, pickles are completely unaware of lazy alignment. It would have to be encoded in type descriptions generated by the compiler using TipeDesc and read by pickles using RTTipe. Most troubling to me is what looks like a linguistic Pandora's box. The pragma can be associated with any constant, variable, or type _declaration_ (not type definition), with the result that different values of the same type can actually be different in their alignment rules and thus their layout. Similarly for different identifiers equated to the same type. Although the effects of this could possibly be hidden from the programmer in purely safe code, not so with unsafe code. I haven't thoroughly thought this through, but seems to me to really fly in the face of the whole typing philosophy of the language. For example, if pickles were to read in an object value, and there were >1 variants of the object's type in the reading program, differing only in the alignment rules, how would it decide which one to build? In fact, ignoring pickles altogether and just looking at a single program, if the object's type doesn't actually uniquely give its memory layout, how can it be accessed correctly? Additionally, a quick look at the compiler suggests it won't generate correct code for whole record assignment when the LHS and RHS are the same type but have different alignment characteristics. The more I think about it, it seems the only workable possibilities are: 1) Require the pragma to be associated only with a type _definition_ not a declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make this a property of the type that propagates to all names for the type and all variables, constants, etc. Also, this would make this property a part of the type signature that pickles uses when reading, -OR- 2) Forget it altogether. What do people think? -- ------------------------------------------------------------- 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 Mon Feb 11 10:15:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: <20080211091341.D290C10D4527@birch.elegosoft.com> References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:29:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:29:10 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080211092401.1068410D466B@birch.elegosoft.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: Does anyone else find it bothersome that you can't introduce VARs anywhere? Kind of like in C++? Ok, or if you grant that frame size doesn't matter THAT much, and the compiler might do stack packing anyway, you can move all your locals up top like typical C, but still, how about for the module initializer? Still it seems good to me to do manual stack packing since it is often so easy.. WITH helps, but only for "relative constants". It would be nice if the code below could have still loops until t0 != t1, but the repeat condition is outside the scope in which t1 is available. This feels quite lame.. - Jay > Date: Mon, 11 Feb 2008 10:24:00 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:24:00> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > Log message:> no need for globals here..> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:35:16 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:35:16 +0000 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 11 Feb 2008 09:15:50 +0000Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) )(Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 11 10:58:18 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 11 Feb 2008 01:58:18 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Mon, 11 Feb 2008 09:29:10 GMT." Message-ID: <200802110958.m1B9wJ9u035766@camembert.async.caltech.edu> Jay writes: >--_568f4bdf-b056-453b-9c29-b8dff8a8bb4c_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Does anyone else find it bothersome that you can't introduce VARs anywhere?= > Kind of like in C++? No. From jayk123 at hotmail.com Mon Feb 11 11:13:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:13:09 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? Message-ID: I know this won't be popular but... over in m3-db\odbc\src, there is POSIX and WIN32, and they are ALMOST identical. The differences are the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. In Win32 all the <*external*> pragmas have WINAPI. In Posix, they lack it. For this and other reasons, I suggest that all CM3 frontends accept but silentlyignore the Win32/x86 calling conventions in <*external*> pragmas,similar to what the non-x86 Windows compilers do. The other reasons would be the "FARPROC" warning that I already cleared up otherwise. And anything else minor that comes up. I know this won't be popular but I REALLY REALLY REALLY believe is the right thing.It is a small safe change that will allow a little more Modula-3 source portability. A similar suggestion would be to change the default calling convention in Modula-3,it would very possibly reduce code size, but is very very very much a breakingchange so probably can never happen.Better probably would be to a) add a switch for this b) extend the .m3exportsor whatnot files to indicate what switch was used. A "blanket pragma" might also be good, so that the various *.i3 files cansay just to assume __stdcall for the rest of the file instead of annotating each functions. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 11:20:59 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 11:20:59 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <1202725259.8543.22.camel@faramir.m3w.org> Why would we, when in M3 we can have blocks as statements? Isn't that a mechanism to localize scope even more? d On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and the > compiler might do stack packing anyway, you can move all your locals > up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is often > so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 != > t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > ______________________________________________________________________ > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > > ______________________________________________________________________ > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 11:34:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:34:19 +0000 Subject: [M3devel] __declspec(dllimport)? Message-ID: __declspec(dllimport) is a nice little cheap optimization on Windows. When you are calling a function that you will be dynamically linking to, it saves one instructions per call. On Windows, the way dynamic linking works is that for all your imports, there is one array of pointers in your .dll/.exe. It could actually be discontiguous. It is an array per .dll rather, with a terminal NULL for each .dll you import from. All the dynamic loader does is write pointers into this array at load time. It does not have to, like, go all through your code patching stuff up. If you just call Foo, but end up importing Foo, the linker generates a one instruction function: Foo: jmp dword ptr[__imp__Foo] __imp__Foo is in that array that gets patched up. However if you declare Foo to be __declspec(dllimport), the compiler will instead of: call Foo generate: call dword ptr[__imp__Foo] in fact, if you have multiple nearby calls to Foo, the compiler knows these pointers are "relatively const" and will fetch the pointer and hold it in a register and make the calls through the register. There is a problem with __declspec(dllimport). Essentially, you know, for every imported function Foo, there is somewhere out there someone implementing it. They are not importing it. They are exporting it. While getting this declaration wrong is actually "ok", it ends up costing the implementer an extra instruction on their calls, and generates a linker warning ("importing local function"). So what ends up happening usually is either a) the implementer doesn't #include his own header files, generally a bad bad bad idea or b) for every .dll bar.dll, a macro is made up BARAPI and then the code usually goes like: #ifndef BARAPI #define BARAPI __declspec(dllimport) #endif BARAPI void __stdcall Foo(void); and the implementer will define BARAPI to either be nothing/empty, or __declspec(dllexport). (__declspec(dllexport) is another topic, I'll try not to go into here.) This is a little gross, this proliferation of "cover" macros for __declspec(dllimport). But it IS a nice little optimization. Actually I suspect many people think these annotations are required. But they almost never ever are. But they are nice to have. So, what do people think? Worth some syntax? In <*extern*> pragmas? Gcc already understand this stuff I believe. I think I noticed it when looking at the __stdcall stuff. Another wrinkle here is that Modula-3 has this nice build_standalone() feature, which switches whether or not you dynamically link. It would tend to invalidate statements here, at least about Modula-3 code. On the matter of when __declspec(dllimport) is needed. - I'm not sure about C++ classes. You should just never import then really, but use COM instead, but people do. (COM is just using pure virtual function calls -- ie: calls through structs containing all function pointers, and get a pointer to said struct via a special C creation function). - It is needed for data, at least with Microsoft tools. The GNU tools seem to have some workaround here. Notice I pointed out the linker generates a function for you if you don't make the annotation. You can't intervene on data accesses with a function call, unless, say, you've inserted a function call for every single data access, or if you can still go back and change the code, like at link time. Data imports are rare and I suggest just never use them. But they are much faster when they suffice, true. __declspec(dllexport) can generally just be replaced with a .def file. - again, I don't know about C++ classes - for C++ functions, the .def file will contain some ugly processor-specific mangled names, a little bit difficult/annoying to come up with and put in the .def file, but not impossible by far (link /dump /symbols | findstr /v UNDEF for example) - again, just don't export C++ classes, or mangled/overloaded/etc. names, only export C functions and you are set with a .def file; this also aids compatibility with multiple compilers and languages (!) - (C++ is largely well and good and I can tell you what is good about it, but one thing it is NOT good for is defining dynamically linked interfaces; I think Modula-3 can get into the same trap -- e.g. traffic only in a few base types (integer, text) and opaque types, don't let dynamically linked callers know about your record format/offsets, else you'll have to recompile "too often") __declspec(dllexport) provides no optimization analogous to __declspec(dllimport). - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 11:36:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:36:19 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: Could be my ignorance of Modula-3 then..let me try a bit more.. - Jay > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 11:20:59 +0100> > Why would we, when in M3 we can have blocks as statements? Isn't that a> mechanism to localize scope even more?> > d> > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > Does anyone else find it bothersome that you can't introduce VARs> > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and the> > compiler might do stack packing anyway, you can move all your locals> > up top like typical C, but still, how about for the module> > initializer?> > Still it seems good to me to do manual stack packing since it is often> > so easy..> > WITH helps, but only for "relative constants".> > > > It would be nice if the code below could have still loops until t0 !=> > t1, but the repeat condition is outside the scope in which t1 is> > available. This feels quite lame..> > > > - Jay> > > > > > > > ______________________________________________________________________> > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > > > > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message:> > > no need for globals here..> > > > > > > > > > > ______________________________________________________________________> > Helping your favorite cause is as easy as instant messaging. You IM,> > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 12:04:09 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 12:04:09 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <1202727849.8543.24.camel@faramir.m3w.org> A piece of code, from the middle of somewhere... len:=Wr.Length(swr.wr); data := TextWr.ToText(swr.wr); VAR s: Ctypes.char_star := M3toC.CopyTtoS(data); ff: ADDRESS := LOOPHOLE(s, ADDRESS); a: UNTRACED REF CHAR; spent: CARDINAL := 0; checkSum: Word.T := 0; BEGIN a := ff; WITH sum = NEW(Sumator) DO sum.reset(); > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote: > Why would we, when in M3 we can have blocks as statements? Isn't that a > mechanism to localize scope even more? > > d > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++? > > Ok, or if you grant that frame size doesn't matter THAT much, and the > > compiler might do stack packing anyway, you can move all your locals > > up top like typical C, but still, how about for the module > > initializer? > > Still it seems good to me to do manual stack packing since it is often > > so easy.. > > WITH helps, but only for "relative constants". > > > > It would be nice if the code below could have still loops until t0 != > > t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame.. > > > > - Jay > > > > > > > > ______________________________________________________________________ > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > To: m3commit at elegosoft.com > > > From: jkrell at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message: > > > no need for globals here.. > > > > > > > > > > > ______________________________________________________________________ > > Helping your favorite cause is as easy as instant messaging. You IM, > > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 12:23:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:23:18 +0000 Subject: [M3devel] size_t? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = INTEGER; really? it is signed? and we are sure this is going to be 64 bits on 64 bit targets? size_t and ptrdiff_t ought to be in BasicCtypes, right?That has a 32 bit and 64 bit version, at least. Does INTEGER effectively equal int or ptrdiff_t? - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 12:28:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:28:01 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202727849.8543.24.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <1202727849.8543.24.camel@faramir.m3w.org> Message-ID: ok thanks, done > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 12:04:09 +0100> > A piece of code, from the middle of somewhere...> > len:=Wr.Length(swr.wr);> data := TextWr.ToText(swr.wr);> VAR> s: Ctypes.char_star := M3toC.CopyTtoS(data);> ff: ADDRESS := LOOPHOLE(s, ADDRESS);> a: UNTRACED REF CHAR;> > spent: CARDINAL := 0;> checkSum: Word.T := 0;> BEGIN> a := ff;> WITH sum = NEW(Sumator) DO> sum.reset();> > > > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote:> > Why would we, when in M3 we can have blocks as statements? Isn't that a> > mechanism to localize scope even more?> > > > d> > > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs> > > anywhere? Kind of like in C++?> > > Ok, or if you grant that frame size doesn't matter THAT much, and the> > > compiler might do stack packing anyway, you can move all your locals> > > up top like typical C, but still, how about for the module> > > initializer?> > > Still it seems good to me to do manual stack packing since it is often> > > so easy..> > > WITH helps, but only for "relative constants".> > > > > > It would be nice if the code below could have still loops until t0 !=> > > t1, but the repeat condition is outside the scope in which t1 is> > > available. This feels quite lame..> > > > > > - Jay> > > > > > > > > > > > ______________________________________________________________________> > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > > To: m3commit at elegosoft.com> > > > From: jkrell at elego.de> > > > Subject: [M3commit] CVS Update: cm3> > > > > > > > CVSROOT: /usr/cvs> > > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > > > Modified files:> > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message:> > > > no need for globals here..> > > > > > > > > > > > > > > > ______________________________________________________________________> > > Helping your favorite cause is as easy as instant messaging. You IM,> > > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 12:30:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 12:30:37 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Quoting Jay : > I know this won't be popular but... > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > The differences are > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > For this and other reasons, I suggest that all CM3 frontends accept > but silentlyignore the Win32/x86 calling conventions in <*external*> > pragmas,similar to what the non-x86 Windows compilers do. > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing.It is a small safe change that will allow a little > more Modula-3 source portability. If I understand you correctly, you'd like to declare the external procedures as WINAPI in general and let all backends except the Windows one ignore it. We should not call it WINAPI then, I think; what about SYSAPI as a general abstraction? > A similar suggestion would be to change the default calling > convention in Modula-3,it would very possibly reduce code size, but > is very very very much a breakingchange so probably can never > happen.Better probably would be to a) add a switch for this b) > extend the .m3exportsor whatnot files to indicate what switch was > used. We shouldn't change the default calling conventions. That is, we should check very very carefully if there are negative effects of doing this and how we cope with them. Until this has been done, we shouldn't change the default calling conventions :-) > A "blanket pragma" might also be good, so that the various *.i3 > files cansay just to assume __stdcall for the rest of the file > instead of annotating each functions. You're talking about a pragma default for all declarations in a file, aren't you? I wouldn't object to that, but it would probably need some compiler extensions, wouldn't 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 Mon Feb 11 13:41:39 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:41:39 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: Olaf, yes you understand me. I strongly object to calling it SYSAPI however, or pretty much any attempt at further abstraction here. I would consider some sort of qualifier that says when to pay attention, when to ignore. For example using a platform name, <*external NT386:WINAPI*>. This is edging toward "preprocessing" but an incredibly small step. (Even though a big problem with preprocessing is rampant context sensitivity, sensitivity to what the target is, and reparsing for every target, is reasonable, and is how M3 already works.) It isn't the "system" calling convention really, it is just very commonly used by the "OS". The "OS" is just a bunch of .dlls, and many of them happen to use __stdcall aka WINAPI a lot, but not all, and not for all functions. "system" MIGHT be how you call the kernel, but that is different. (calling the kernel is not directly exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). msvcrt.dll uses __cdecl for the most part. Anything that accepts varargs, which is very few functions, uses __cdecl, out of necessity (at least give a "normal" point of view, I did used to use a system where calleee popped varargs...). If you write drivers, a small number of functions are __fastcall. I would rather drop the synonyms and just have __cdecl, __fastcall, __stdcall, than to invent "SYSAPI". However I don't really want to do that, "WINAPI" and the other names are useful for a more literal translation of headers. There is a mix of calling conventions on x86 Windows and there is not really one "SYSAPI". The negative affects of changing the default calling convention is breaking all existing dynamic links where you only rebuild one side and where the calling convention wasn't explicit (all of them). Very very bad. > you'd like to declare the external procedures as WINAPI in general Not quite in general perhaps. But I guess any file for which someone has portable C and it is built for NT386 and anything else. Explicit calling conventions are always reasonable on NT386 and never reasonable anywhere else. The Visual C++ compiler has a command line switch as to what the default calling convention is, and widely used headers should work no matter what is the default. - Jay > Date: Mon, 11 Feb 2008 12:30:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > > I know this won't be popular but...> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> > The differences are> > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed.> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> > For this and other reasons, I suggest that all CM3 frontends accept > > but silentlyignore the Win32/x86 calling conventions in <*external*> > > pragmas,similar to what the non-x86 Windows compilers do.> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.It is a small safe change that will allow a little > > more Modula-3 source portability.> > If I understand you correctly, you'd like to declare the external> procedures as WINAPI in general and let all backends except the> Windows one ignore it. We should not call it WINAPI then, I think;> what about SYSAPI as a general abstraction?> > > A similar suggestion would be to change the default calling > > convention in Modula-3,it would very possibly reduce code size, but > > is very very very much a breakingchange so probably can never > > happen.Better probably would be to a) add a switch for this b) > > extend the .m3exportsor whatnot files to indicate what switch was > > used.> > We shouldn't change the default calling conventions. That is, we should> check very very carefully if there are negative effects of doing this> and how we cope with them.> Until this has been done, we shouldn't change the default calling> conventions :-)> > > A "blanket pragma" might also be good, so that the various *.i3 > > files cansay just to assume __stdcall for the rest of the file > > instead of annotating each functions.> > You're talking about a pragma default for all declarations in a> file, aren't you? I wouldn't object to that, but it would> probably need some compiler extensions, wouldn't 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> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 13:48:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:48:23 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211111256.22C8E10D4628@birch.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: Here is another SMALL gripe with the language. The need to put IMPORTS at the top (or is it just common style?), leads to something I have seen several times. You comment out some code, thereby deleting the only/last use of some import, that nets you warnings about unused imports. Granted, they are "only" warnings, but I try to have none. Also granted, you can either comment out or just go ahead and remove the imports, easy. It might be nice if the IMPORTS could be adjacent to the code using the IMPORTS, so that they can be comment out or removed together. This "problem" is not unique to Modula-3, by far. In fact, Modula-3 is probably more able to warn about this low cost waste due to its much better module system, compared to say, C and C++ #includes... - Jay > Date: Mon, 11 Feb 2008 12:12:56 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 12:12:56> > Modified files:> cm3/m3-ui/ui/src/winvbt/: WinScreenType.m3 > > Log message:> fix warning about unused import (the use is commented out..would be nice> to be able to move the import to near the code so they can be commented> out together..)> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 14:12:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:12:03 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Quoting Jay : > Olaf, yes you understand me. > > I strongly object to calling it SYSAPI however, or pretty much any > attempt at further abstraction here. > > I would consider some sort of qualifier that says when to pay > attention, when to ignore. > For example using a platform name, <*external NT386:WINAPI*>. > This is edging toward "preprocessing" but an incredibly small step. > (Even though a big problem with preprocessing is rampant context > sensitivity, sensitivity to what the target is, and reparsing for > every target, is reasonable, and is how M3 already works.) > > It isn't the "system" calling convention really, it is just very > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > many of them happen to use __stdcall aka WINAPI a lot, but not all, > and not for all functions. "system" MIGHT be how you call the > kernel, but that is different. (calling the kernel is not directly > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). OK, so it's not system specific, but its system specific that there are multiple calling conventions for Windows. However, I'm still not convinced that this may affect only Windows systems and no others. It may sound academic, but wouldn't it be possible that suddenly Apple (or even some new OS player :) comes up with similar distinctions? I think we shouldn't implement a pragma convention that is usable only for Windows, but one that is more generic. If we can just extend your example to something like <*EXTERNAL NT386:WINAPI, ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> this would be better. As for the semantic differences on different target platforms, I think we could live with them given that all this stuff is system dependent and unsafe anyway, but I'd like to hear the opinion of others on this topic, too. Olaf > msvcrt.dll uses __cdecl for the most part. > Anything that accepts varargs, which is very few functions, uses > __cdecl, out of necessity (at least give a "normal" point of view, I > did used to use a system where calleee popped varargs...). > If you write drivers, a small number of functions are __fastcall. > I would rather drop the synonyms and just have __cdecl, __fastcall, > __stdcall, than to invent "SYSAPI". > However I don't really want to do that, "WINAPI" and the other names > are useful for a more literal translation of headers. > There is a mix of calling conventions on x86 Windows and there is > not really one "SYSAPI". > > The negative affects of changing the default calling convention is > breaking all existing dynamic links where you only rebuild one side > and where the calling convention wasn't explicit (all of them). Very > very bad. > > > you'd like to declare the external procedures as WINAPI in general > > Not quite in general perhaps. > But I guess any file for which someone has portable C and it is > built for NT386 and anything else. > Explicit calling conventions are always reasonable on NT386 and > never reasonable anywhere else. > The Visual C++ compiler has a command line switch as to what the > default calling convention is, and widely used headers should work > no matter what is the default. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 11 14:17:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:17:56 +0100 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Quoting Jay : > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and > C++ #includes.. I wouldn't like to see any changes here. It is good that all the imports are explicit, and it is good that they are at the top (to define the dependencies). It's not much effort to add or remove an import for debugging etc. If you are really lazy, you can always use the NOWARN pragma: IMPOPRT IO <*NOWARN*> to suppres the warnings for that declaration. That was not your point though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Feb 11 14:31:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:31:41 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: I don't think anyone else will commit the error of having multiple calling conventions. It's a bad place to be. Granted, kernels often do have an unusual calling convention, but that gets wrapped up in something "normal". > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> In practice this will only ever be: > <*EXTERNAL NT386:WINAPI *> and I am satisfied. :) oh, btw, the other obvious: > <*NT386:EXTERNAL WINAPI *> or even in general both -- pragms can all be prefixed with a platform. In practise, "external" is platform-independent, calling convention is not. There might be exceptions, where particular platforms require a Modula-3 wrapper. As Cygwin had briefly for semaphore initialization. I guess this really does in general resemble preprocessing, only by target, only of pragmas, and the point really is to limit per-platform branching when the platforms are indeed extremely similar. This is a common pattern -- if'ing stuff midly, if'ing stuff to heck, vs. splitting out in separate implementation with no ugly if'ing. OpenGL is in a similar boat here, except that it seems to be a disproof. It appears the Cygwin/X OpenGL functions use __cdecl while the Microsoft ones use __stdcall. Again the *.i3 files are almost the same, except for calling conventions, but it seems the "NT386 POSIX" variant uses a different calling convention than the "NT386 WIN32" variant. I am not 100% what is going on in OpenGL. Building "std" for NT386GNU gets at least as far as anim3d, however I haven't run much of the code at all -- only enough of cm3 to see it has a problem with paths... I'm still just using a "regular" NT386 in a sort of cross scenario. - Jay > Date: Mon, 11 Feb 2008 14:12:03 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > Olaf, yes you understand me.> >> > I strongly object to calling it SYSAPI however, or pretty much any > > attempt at further abstraction here.> >> > I would consider some sort of qualifier that says when to pay > > attention, when to ignore.> > For example using a platform name, <*external NT386:WINAPI*>.> > This is edging toward "preprocessing" but an incredibly small step.> > (Even though a big problem with preprocessing is rampant context > > sensitivity, sensitivity to what the target is, and reparsing for > > every target, is reasonable, and is how M3 already works.)> >> > It isn't the "system" calling convention really, it is just very > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > many of them happen to use __stdcall aka WINAPI a lot, but not all, > > and not for all functions. "system" MIGHT be how you call the > > kernel, but that is different. (calling the kernel is not directly > > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is).> > OK, so it's not system specific, but its system specific that there> are multiple calling conventions for Windows. However, I'm still not> convinced that this may affect only Windows systems and no others.> It may sound academic, but wouldn't it be possible that suddenly> Apple (or even some new OS player :) comes up with similar distinctions?> > I think we shouldn't implement a pragma convention that is usable> only for Windows, but one that is more generic. If we can just> extend your example to something like> > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*>> > this would be better.> > As for the semantic differences on different target platforms, I think> we could live with them given that all this stuff is system dependent> and unsafe anyway, but I'd like to hear the opinion of others on this> topic, too.> > Olaf> > > msvcrt.dll uses __cdecl for the most part.> > Anything that accepts varargs, which is very few functions, uses > > __cdecl, out of necessity (at least give a "normal" point of view, I > > did used to use a system where calleee popped varargs...).> > If you write drivers, a small number of functions are __fastcall.> > I would rather drop the synonyms and just have __cdecl, __fastcall, > > __stdcall, than to invent "SYSAPI".> > However I don't really want to do that, "WINAPI" and the other names > > are useful for a more literal translation of headers.> > There is a mix of calling conventions on x86 Windows and there is > > not really one "SYSAPI".> >> > The negative affects of changing the default calling convention is > > breaking all existing dynamic links where you only rebuild one side > > and where the calling convention wasn't explicit (all of them). Very > > very bad.> >> > > you'd like to declare the external procedures as WINAPI in general> >> > Not quite in general perhaps.> > But I guess any file for which someone has portable C and it is > > built for NT386 and anything else.> > Explicit calling conventions are always reasonable on NT386 and > > never reasonable anywhere else.> > The Visual C++ compiler has a command line switch as to what the > > default calling convention is, and widely used headers should work > > no matter what is the default.> > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 14:33:42 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:33:42 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Message-ID: > If you are really lazy, you can always use the NOWARN pragma: What if I am really really really lazy? :) > I wouldn't like to see any changes here. ok. - Jay > Date: Mon, 11 Feb 2008 14:17:56 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] imports anywhere?> > Quoting Jay :> > > Here is another SMALL gripe with the language.> > The need to put IMPORTS at the top (or is it just common style?), > > leads to something I have seen several times.> > You comment out some code, thereby deleting the only/last use of > > some import, that nets you warnings about unused imports. Granted, > > they are "only" warnings, but I try to have none. Also granted, you > > can either comment out or just go ahead and remove the imports, easy.> >> > It might be nice if the IMPORTS could be adjacent to the code using > > the IMPORTS, so that they can be comment out or removed together.> >> > This "problem" is not unique to Modula-3, by far.> > In fact, Modula-3 is probably more able to warn about this low cost > > waste due to its much better module system, compared to say, C and > > C++ #includes..> > I wouldn't like to see any changes here.> > It is good that all the imports are explicit, and it is good that> they are at the top (to define the dependencies). It's not much> effort to add or remove an import for debugging etc.> > If you are really lazy, you can always use the NOWARN pragma:> > IMPOPRT IO <*NOWARN*>> > to suppres the warnings for that declaration. That was not your> point though.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 15:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 14:38:14 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211142730.E6B3A10D4655@birch.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: It'd be nice if I could declare externals in modules. In this example, setitimer_ only exists for the wrapper implementation. I don't need it to be visible outside the one module that uses it. I guess I could push it into an unexposed interface, even dedicate "internal.i3" to it?Is that an ok idiom? It's another problem that I don't know what to call these things.. - Jay > Date: Mon, 11 Feb 2008 15:27:30 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 15:27:30> > Modified files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 m3makefile > Added files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.m3 > > Log message:> make setitimer(ITIMER_VIRTUAL) always succeed, even though Cygwin> would always fail it (not so accurate a Unix emulation eh?)> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 16:02:40 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 16:02:40 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Quoting Jay : > It'd be nice if I could declare externals in modules. > In this example, setitimer_ only exists for the wrapper implementation. > I don't need it to be visible outside the one module that uses it. > I guess I could push it into an unexposed interface, even dedicate > "internal.i3" to it?Is that an ok idiom? Yes, use an internal interface of the package. But you should use another name (something longer and more unique), since the CM3 builder still has problems with multiple defined units AFAIK. This is something that should really be fixed, but that's another topic. (We'd need hierarchical name spaces, but introduce them in a compatible way.) Olaf > It's another problem that I don't know what to call these things.. This usually is _my_ problem :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 11 17:23:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:23:47 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: Message-ID: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Do we know that this actually results in any real performance improvement. On Feb 11, 2008, at 5:34 AM, Jay wrote: > __declspec(dllimport) is a nice little cheap optimization on Windows. > When you are calling a function that you will be dynamically > linking to, it saves one instructions per call. > > On Windows, the way dynamic linking works is that for all your > imports, there is one array of pointers in your .dll/.exe. > It could actually be discontiguous. It is an array per .dll rather, > with a terminal NULL for each .dll you import from. All the dynamic > loader does is write pointers into this array at load time. It does > not have to, like, go all through your code patching stuff up. > > If you just call Foo, but end up importing Foo, the linker > generates a one instruction function: > Foo: > jmp dword ptr[__imp__Foo] > > __imp__Foo is in that array that gets patched up. > > However if you declare Foo to be __declspec(dllimport), the > compiler will instead of: > call Foo > generate: > call dword ptr[__imp__Foo] > > in fact, if you have multiple nearby calls to Foo, the compiler > knows these pointers are "relatively const" and will fetch the > pointer and hold it in a register and make the calls through the > register. > > There is a problem with __declspec(dllimport). > Essentially, you know, for every imported function Foo, there is > somewhere out there someone implementing it. > They are not importing it. They are exporting it. > While getting this declaration wrong is actually "ok", it ends up > costing the implementer an extra instruction on their calls, and > generates a linker warning ("importing local function"). > > So what ends up happening usually is either a) the implementer > doesn't #include his own header files, generally a bad bad bad idea > or b) for every .dll bar.dll, a macro is made up BARAPI and then > the code usually goes like: > > #ifndef BARAPI > #define BARAPI __declspec(dllimport) > #endif > > BARAPI void __stdcall Foo(void); > > and the implementer will define BARAPI to either be nothing/empty, > or __declspec(dllexport). > (__declspec(dllexport) is another topic, I'll try not to go into > here.) > > This is a little gross, this proliferation of "cover" macros for > __declspec(dllimport). > But it IS a nice little optimization. > Actually I suspect many people think these annotations are required. > But they almost never ever are. But they are nice to have. > > So, what do people think? > Worth some syntax? In <*extern*> pragmas? > Gcc already understand this stuff I believe. > I think I noticed it when looking at the __stdcall stuff. > > Another wrinkle here is that Modula-3 has this nice build_standalone > () feature, which switches whether or not you dynamically link. It > would tend to invalidate statements here, at least about Modula-3 > code. > > On the matter of when __declspec(dllimport) is needed. > - I'm not sure about C++ classes. You should just never import > then really, but use COM instead, but people do. > (COM is just using pure virtual function calls -- ie: calls > through structs containing all function pointers, and get a pointer > to said struct via a special C creation function). > > - It is needed for data, at least with Microsoft tools. The GNU > tools seem to have some workaround here. > Notice I pointed out the linker generates a function for you if > you don't make the annotation. You can't intervene on data accesses > with a function call, unless, say, you've inserted a function call > for every single data access, or if you can still go back and > change the code, like at link time. Data imports are rare and I > suggest just never use them. But they are much faster when they > suffice, true. > > __declspec(dllexport) can generally just be replaced with a .def file. > - again, I don't know about C++ classes > - for C++ functions, the .def file will contain some ugly > processor-specific mangled names, a little bit difficult/annoying > to come up with and put in the .def file, but not impossible by far > (link /dump /symbols | findstr /v UNDEF for example) > - again, just don't export C++ classes, or mangled/overloaded/ > etc. names, only export C functions and you are set with a .def > file; this also aids compatibility with multiple compilers and > languages (!) > - (C++ is largely well and good and I can tell you what is good > about it, but one thing it is NOT good for is defining dynamically > linked interfaces; I think Modula-3 can get into the same trap -- > e.g. traffic only in a few base types (integer, text) and opaque > types, don't let dynamically linked callers know about your record > format/offsets, else you'll have to recompile "too often") > > __declspec(dllexport) provides no optimization analogous to > __declspec(dllimport). > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Feb 11 17:26:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:26:50 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: Why not simply default EXTERNAL on Win32 to WINAPI instead? That way, all EXTERNALs will look the same but you won't clutter up non- Win32 with ugly WINAPI. On Feb 11, 2008, at 5:13 AM, Jay wrote: > I know this won't be popular but... > > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > > The differences are > > the UNUSED type SQLHWND is ADDRESS or HWND > This should just be removed. > > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > > For this and other reasons, I suggest that all CM3 frontends accept > but silently > ignore the Win32/x86 calling conventions in <*external*> pragmas, > similar to what the non-x86 Windows compilers do. > > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing. > It is a small safe change that will allow a little more Modula-3 > source portability. > > A similar suggestion would be to change the default calling > convention in Modula-3, > it would very possibly reduce code size, but is very very very much > a breaking > change so probably can never happen. > Better probably would be to a) add a switch for this b) extend > the .m3exports > or whatnot files to indicate what switch was used. > > A "blanket pragma" might also be good, so that the various *.i3 > files can > say just to assume __stdcall for the rest of the file instead of > annotating each functions. > > - Jay > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:28:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:28:56 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: <38355684-DFFB-43B0-81D9-D6745EA195BB@cs.purdue.edu> On Feb 11, 2008, at 8:31 AM, Jay wrote: > I don't think anyone else will commit the error of having multiple > calling conventions. > It's a bad place to be. > Granted, kernels often do have an unusual calling convention, but > that gets wrapped up in something "normal". > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > In practice this will only ever be: > > > <*EXTERNAL NT386:WINAPI *> I can live with this. > > > and I am satisfied. :) > > oh, btw, the other obvious: > > <*NT386:EXTERNAL WINAPI *> > > or even in general both -- pragms can all be prefixed with a platform. > In practise, "external" is platform-independent, calling convention > is not. > > There might be exceptions, where particular platforms require a > Modula-3 wrapper. As Cygwin had briefly for semaphore > initialization. I guess this really does in general resemble > preprocessing, only by target, only of pragmas, and the point > really is to limit per-platform branching when the platforms are > indeed extremely similar. > > This is a common pattern -- if'ing stuff midly, if'ing stuff to > heck, vs. splitting out in separate implementation with no ugly > if'ing. > > OpenGL is in a similar boat here, except that it seems to be a > disproof. > It appears the Cygwin/X OpenGL functions use __cdecl while the > Microsoft ones use __stdcall. > Again the *.i3 files are almost the same, except for calling > conventions, but it seems the "NT386 POSIX" variant uses a > different calling convention than the "NT386 WIN32" variant. > > I am not 100% what is going on in OpenGL. Building "std" for > NT386GNU gets at least as far as anim3d, however I haven't run much > of the code at all -- only enough of cm3 to see it has a problem > with paths... I'm still just using a "regular" NT386 in a sort of > cross scenario. > > - Jay > > > > Date: Mon, 11 Feb 2008 14:12:03 +0100 > > From: wagner at elegosoft.com > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] <*external winapi*> silently ignored on > all platforms? > > > > Quoting Jay : > > > Olaf, yes you understand me. > > > > > > I strongly object to calling it SYSAPI however, or pretty much any > > > attempt at further abstraction here. > > > > > > I would consider some sort of qualifier that says when to pay > > > attention, when to ignore. > > > For example using a platform name, <*external NT386:WINAPI*>. > > > This is edging toward "preprocessing" but an incredibly small > step. > > > (Even though a big problem with preprocessing is rampant context > > > sensitivity, sensitivity to what the target is, and reparsing for > > > every target, is reasonable, and is how M3 already works.) > > > > > > It isn't the "system" calling convention really, it is just very > > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > > many of them happen to use __stdcall aka WINAPI a lot, but not > all, > > > and not for all functions. "system" MIGHT be how you call the > > > kernel, but that is different. (calling the kernel is not directly > > > exposed in Win32, "kernel32.dll" is not the kernel, > ntoskrnl.exe is). > > > > OK, so it's not system specific, but its system specific that there > > are multiple calling conventions for Windows. However, I'm still not > > convinced that this may affect only Windows systems and no others. > > It may sound academic, but wouldn't it be possible that suddenly > > Apple (or even some new OS player :) comes up with similar > distinctions? > > > > I think we shouldn't implement a pragma convention that is usable > > only for Windows, but one that is more generic. If we can just > > extend your example to something like > > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > > > this would be better. > > > > As for the semantic differences on different target platforms, I > think > > we could live with them given that all this stuff is system > dependent > > and unsafe anyway, but I'd like to hear the opinion of others on > this > > topic, too. > > > > Olaf > > > > > msvcrt.dll uses __cdecl for the most part. > > > Anything that accepts varargs, which is very few functions, uses > > > __cdecl, out of necessity (at least give a "normal" point of > view, I > > > did used to use a system where calleee popped varargs...). > > > If you write drivers, a small number of functions are __fastcall. > > > I would rather drop the synonyms and just have __cdecl, > __fastcall, > > > __stdcall, than to invent "SYSAPI". > > > However I don't really want to do that, "WINAPI" and the other > names > > > are useful for a more literal translation of headers. > > > There is a mix of calling conventions on x86 Windows and there is > > > not really one "SYSAPI". > > > > > > The negative affects of changing the default calling convention is > > > breaking all existing dynamic links where you only rebuild one > side > > > and where the calling convention wasn't explicit (all of them). > Very > > > very bad. > > > > > > > you'd like to declare the external procedures as WINAPI in > general > > > > > > Not quite in general perhaps. > > > But I guess any file for which someone has portable C and it is > > > built for NT386 and anything else. > > > Explicit calling conventions are always reasonable on NT386 and > > > never reasonable anywhere else. > > > The Visual C++ compiler has a command line switch as to what the > > > default calling convention is, and widely used headers should work > > > no matter what is the default. > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:33:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:33:07 -0500 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <8B8213B4-3DBF-47CE-BC3E-1EE96B5F43F6@cs.purdue.edu> On Feb 11, 2008, at 4:15 AM, Jay wrote: > Aren't we better off with more VAR parameters and fewer UNTRACED REFs? > That way more interfaces/modules can be "safe", as this one changed? Indeed! I agree. > > > (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) > (Maybe a "DJGPP" target will satisfy? :) ) I barely care about Windows :-), whatever version you choose. > > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:13:41 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:13:41 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > > > Log message: > > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > > instead of GetSystemTime + SystemTimeToFileTime > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:34:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:34:54 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> You can, except you need to explicitly give the block scope: VAR ... BEGIN ... END; I find this much better than C++ where the scope of the new variable is imprecisely defined. On Feb 11, 2008, at 4:29 AM, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and > the compiler might do stack packing anyway, you can move all your > locals up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is > often so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 ! > = t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:38:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:38:48 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> On Feb 11, 2008, at 6:23 AM, Jay wrote: > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > INTEGER; > > really? it is signed? > and we are sure this is going to be 64 bits on 64 bit targets? > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > That has a 32 bit and 64 bit version, at least. These are OS-dependent! They should not be in BasicCtypes. > > > Does INTEGER effectively equal int or ptrdiff_t? > > - Jay > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:40:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:40:11 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: I hate imports that are scattered throughout since it hides dependencies deep in the guts of the code. Much better to have them explicit at the top! On Feb 11, 2008, at 7:48 AM, Jay wrote: > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and C > ++ #includes.. From hosking at cs.purdue.edu Mon Feb 11 17:41:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:41:24 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: Please -- no hierarchical namespaces. Ultimately, they need a definitive hierarchy anyway. On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > Quoting Jay : > >> It'd be nice if I could declare externals in modules. >> In this example, setitimer_ only exists for the wrapper >> implementation. >> I don't need it to be visible outside the one module that uses it. >> I guess I could push it into an unexposed interface, even >> dedicate "internal.i3" to it?Is that an ok idiom? > > Yes, use an internal interface of the package. But you should use > another name (something longer and more unique), since the CM3 > builder still has problems with multiple defined units AFAIK. > > This is something that should really be fixed, but that's another > topic. (We'd need hierarchical name spaces, but introduce them in > a compatible way.) > > Olaf > >> It's another problem that I don't know what to call these things.. > > This usually is _my_ problem :-) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Mon Feb 11 17:42:00 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:42:00 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Message-ID: <20080211164200.GB20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: > Do we know that this actually results in any real performance > improvement. Not clear -- hardware is getting pretty clever at doing at run-time the things that compilers used to sweat blood doing at compile time. I suspect that with fetch-and-branch-predictiong processors, the difference may unmeasurable. -- hendrik From hendrik at topoi.pooq.com Mon Feb 11 17:50:54 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:50:54 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211165054.GC20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:40:11AM -0500, Tony Hosking wrote: > I hate imports that are scattered throughout since it hides > dependencies deep in the guts of the code. Much better to have them > explicit at the top! > > On Feb 11, 2008, at 7:48 AM, Jay wrote: > > >Here is another SMALL gripe with the language. > >The need to put IMPORTS at the top (or is it just common style?), > >leads to something I have seen several times. > >You comment out some code, thereby deleting the only/last use of > >some import, that nets you warnings about unused imports. Granted, > >they are "only" warnings, but I try to have none. Also granted, you > >can either comment out or just go ahead and remove the imports, easy. > > > >It might be nice if the IMPORTS could be adjacent to the code using > >the IMPORTS, so that they can be comment out or removed together. > > > >This "problem" is not unique to Modula-3, by far. > >In fact, Modula-3 is probably more able to warn about this low cost > >waste due to its much better module system, compared to say, C and C > >++ #includes.. > I don't know if this is still the case, but long long ago, when I was reading the OS/2 port of Modula 3, there seemed to be an early phase that determined which source files had to be compiled. It could determine this from just the beginnings of the source files, and did not have to do full-scale Modula 3 parsing. I thought it a clever engineering trick. -- hendrik From rcoleburn at scires.com Mon Feb 11 17:58:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 11 Feb 2008 11:58:15 -0500 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <47B03853.1E75.00D7.1@scires.com> Jay: Not sure exactly what you are doing and how my answer will impact what you are doing, but here is my 2 cents. If there is stuff out there to deal with these old computers, we shouldn't remove it just because they are old. I still have Modula-3 code that is running on old computers. Indeed, the government tends to have some interesting requirements to keep alive certain systems that use old technology. I have delivered many systems over the course of my career whose actual lifetime was much longer than what anyone projected in the beginning. If we remove support for the old stuff, then we shoot ourselves in the foot for any type of support on these old systems. Indeed, I've recently been approached about making some changes to a system that I first developed back in the late 1990's. It is still around and working. One of the system components has been upgraded and they want me to make software changes to let the Modula-3 code work with the new component. This software controls and monitors satellite radio communications systems. Regards, Randy >>> Jay 2/11/2008 4:35 AM >>> ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs? That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/11 10:13:41 > > Modified files: > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message: > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > instead of GetSystemTime + SystemTimeToFileTime > Need to know the score, the latest news, or you need your Hotmail*-get your "fix". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) Climb to the top of the charts! Play the word scramble challenge with star power. Play now! ( http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 17:59:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:59:40 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <20080211164200.GB20791@topoi.pooq.com> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> Message-ID: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> My thoughts exactly. Let's not expend effort for no gain! On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote: > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: >> Do we know that this actually results in any real performance >> improvement. > > Not clear -- hardware is getting pretty clever at doing at run-time > the > things that compilers used to sweat blood doing at compile time. I > suspect that with fetch-and-branch-predictiong processors, the > difference may > unmeasurable. > > -- hendrik From wagner at elegosoft.com Mon Feb 11 18:19:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 18:19:59 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Quoting Tony Hosking : > Please -- no hierarchical namespaces. Ultimately, they need a > definitive hierarchy anyway. I wasn't going to write the code, so no need to worry. However, if this is not the solution we aim at, then we need to do something else about the increasing probability of the builder failing because some module in a completely different package which I don't even use directly happens to have the same name as my internal module and thus cannot be compiled. Or even worse: if I use two packages that happen to contain one module of the same name and have never been used together before. Olaf PS: This reminds me of Leslie Lamports definition of distributed computing: when a computer you didn't even know existed can render your own computer unusable :) > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> Quoting Jay : >> >>> It'd be nice if I could declare externals in modules. >>> In this example, setitimer_ only exists for the wrapper implementation. >>> I don't need it to be visible outside the one module that uses it. >>> I guess I could push it into an unexposed interface, even dedicate >>> "internal.i3" to it?Is that an ok idiom? >> >> Yes, use an internal interface of the package. But you should use >> another name (something longer and more unique), since the CM3 >> builder still has problems with multiple defined units AFAIK. >> >> This is something that should really be fixed, but that's another >> topic. (We'd need hierarchical name spaces, but introduce them in >> a compatible way.) >> >> Olaf >> >>> It's another problem that I don't know what to call these things.. >> >> This usually is _my_ problem :-) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Feb 11 18:52:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 12:52:33 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: This would be a bigger issue if we had dynamic loading like Java. To some degree, m3makefile imports give us some protection against name clashes. But, I do see your point that a name clash may prevent reuse of separately developed packages. On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Please -- no hierarchical namespaces. Ultimately, they need a >> definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf > > PS: This reminds me of Leslie Lamports definition of distributed > computing: when a computer you didn't even know existed > can render your own computer unusable :) > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >> >>> Quoting Jay : >>> >>>> It'd be nice if I could declare externals in modules. >>>> In this example, setitimer_ only exists for the wrapper >>>> implementation. >>>> I don't need it to be visible outside the one module that uses it. >>>> I guess I could push it into an unexposed interface, even >>>> dedicate "internal.i3" to it?Is that an ok idiom? >>> >>> Yes, use an internal interface of the package. But you should use >>> another name (something longer and more unique), since the CM3 >>> builder still has problems with multiple defined units AFAIK. >>> >>> This is something that should really be fixed, but that's another >>> topic. (We'd need hierarchical name spaces, but introduce them in >>> a compatible way.) >>> >>> Olaf >>> >>>> It's another problem that I don't know what to call these things.. >>> >>> This usually is _my_ problem :-) >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hendrik at topoi.pooq.com Mon Feb 11 21:06:13 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 15:06:13 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <20080211200613.GA20997@topoi.pooq.com> On Mon, Feb 11, 2008 at 06:19:59PM +0100, Olaf Wagner wrote: > Quoting Tony Hosking : > > >Please -- no hierarchical namespaces. Ultimately, they need a > >definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf Packages are a lot like modules on a larger scale. Maybe we should be able to syntactically nest modules? And enable modules to export some of their submodules? Or, if the source file gets unwieldy (it will!), use the nesting structure of directories as part of the syntax of the language? Or, for another approach: The various Eiffel implementations have separate module-interconnection language in which they get to collect modules into groups, and indicate some are internal to the group, and also things like <>, or <>. They set this up with programming-language syntax, syntactic nesting, indentation, and so forth. It seems to work, and you don't have to embed everything into an unweildy world-wide, global namespace. But the different implementations seem to have grown their own interconnection languages :-( -- hendrik From jayk123 at hotmail.com Mon Feb 11 22:42:30 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:42:30 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: Lack of hierarchical namespaces in Modula-3 has long bugged me, but I actually pretty much got over it. So agreed. :) Yes it sounds like the builder, not the language, has a bug. - Jay > Date: Mon, 11 Feb 2008 18:19:59 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] external in module?> > Quoting Tony Hosking :> > > Please -- no hierarchical namespaces. Ultimately, they need a> > definitive hierarchy anyway.> > I wasn't going to write the code, so no need to worry.> However, if this is not the solution we aim at, then we need to> do something else about the increasing probability of the builder> failing because some module in a completely different package> which I don't even use directly happens to have the same name> as my internal module and thus cannot be compiled. Or even worse:> if I use two packages that happen to contain one module of the> same name and have never been used together before.> > Olaf> > PS: This reminds me of Leslie Lamports definition of distributed> computing: when a computer you didn't even know existed> can render your own computer unusable :)> > > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote:> >> >> Quoting Jay :> >>> >>> It'd be nice if I could declare externals in modules.> >>> In this example, setitimer_ only exists for the wrapper implementation.> >>> I don't need it to be visible outside the one module that uses it.> >>> I guess I could push it into an unexposed interface, even dedicate > >>> "internal.i3" to it?Is that an ok idiom?> >>> >> Yes, use an internal interface of the package. But you should use> >> another name (something longer and more unique), since the CM3> >> builder still has problems with multiple defined units AFAIK.> >>> >> This is something that should really be fixed, but that's another> >> topic. (We'd need hierarchical name spaces, but introduce them in> >> a compatible way.)> >>> >> Olaf> >>> >>> It's another problem that I don't know what to call these things..> >>> >> This usually is _my_ problem :-)> >> -- > >> Olaf Wagner -- elego Software Solutions GmbH> >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:44:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:44:18 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:51:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:51:10 +0000 Subject: [M3devel] size_t? In-Reply-To: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: > These are OS-dependent! They should not be in BasicCtypes. 1) There is no Utypes on Windows. These are very basic types that belong at a very low level. In C++ for example, size_t is provided "automatically" by the compiler, no header is needed. 2) Are they really OS dependent? What OS makes my definitions wrong? On what 32 bit architecture is size_t not an unsigned 32 bit integer and ptrdiff_t not a signed 32 bit integer? Ditto for 64 bit. These should always be the same size as a pointer and with the proper signedness. Even if some of the *.i3 files make size_t = int, is that really correct? And, I assume int vs. long issue is not an issue here. Though they may be different types in C and C++, they need not be in Modula-3 (when they are the same size, of course) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 11:38:48 -0500> To: jayk123 at hotmail.com> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > INTEGER;> >> > really? it is signed?> > and we are sure this is going to be 64 bits on 64 bit targets?> >> > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > That has a 32 bit and 64 bit version, at least.> > These are OS-dependent! They should not be in BasicCtypes.> > >> >> > Does INTEGER effectively equal int or ptrdiff_t?> >> > - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:52:06 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:52:06 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: I guess I should switch the default calling convention and see what the code size difference is. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hendrik at topoi.pooq.comDate: Mon, 11 Feb 2008 21:44:18 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] __declspec(dllimport)? Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:56:55 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:56:55 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: If you want a precise scope in C++, just but in an opening brace. Just like how in Modula-3 (now I know) you can have "BEGIN" almost anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. It isn't often used though, granted. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] introducing VAR in more places?> Date: Mon, 11 Feb 2008 11:34:54 -0500> To: jayk123 at hotmail.com> > You can, except you need to explicitly give the block scope:> > VAR ...> BEGIN> ...> END;> > I find this much better than C++ where the scope of the new variable > is imprecisely defined.> > On Feb 11, 2008, at 4:29 AM, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and > > the compiler might do stack packing anyway, you can move all your > > locals up top like typical C, but still, how about for the module > > initializer?> > Still it seems good to me to do manual stack packing since it is > > often so easy..> > WITH helps, but only for "relative constants".> >> > It would be nice if the code below could have still loops until t0 ! > > = t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame..> >> > - Jay> >> >> >> > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > >> > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3> > >> > > Log message:> > > no need for globals here..> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 22:33:20 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 22:33:20 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <1202765600.8543.32.camel@faramir.m3w.org> But... We DO HAVE dynamic loading, and it's not altogether unlike Java :). Did these patches of mine made to CM3 HEAD? dd On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: > This would be a bigger issue if we had dynamic loading like Java. To > some degree, m3makefile imports give us some protection against name > clashes. But, I do see your point that a name clash may prevent > reuse of separately developed packages. > > On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > >> Please -- no hierarchical namespaces. Ultimately, they need a > >> definitive hierarchy anyway. > > > > I wasn't going to write the code, so no need to worry. > > However, if this is not the solution we aim at, then we need to > > do something else about the increasing probability of the builder > > failing because some module in a completely different package > > which I don't even use directly happens to have the same name > > as my internal module and thus cannot be compiled. Or even worse: > > if I use two packages that happen to contain one module of the > > same name and have never been used together before. > > > > Olaf > > > > PS: This reminds me of Leslie Lamports definition of distributed > > computing: when a computer you didn't even know existed > > can render your own computer unusable :) > > > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> > >>> Quoting Jay : > >>> > >>>> It'd be nice if I could declare externals in modules. > >>>> In this example, setitimer_ only exists for the wrapper > >>>> implementation. > >>>> I don't need it to be visible outside the one module that uses it. > >>>> I guess I could push it into an unexposed interface, even > >>>> dedicate "internal.i3" to it?Is that an ok idiom? > >>> > >>> Yes, use an internal interface of the package. But you should use > >>> another name (something longer and more unique), since the CM3 > >>> builder still has problems with multiple defined units AFAIK. > >>> > >>> This is something that should really be fixed, but that's another > >>> topic. (We'd need hierarchical name spaces, but introduce them in > >>> a compatible way.) > >>> > >>> Olaf > >>> > >>>> It's another problem that I don't know what to call these things.. > >>> > >>> This usually is _my_ problem :-) > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > >>> 23 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 23:03:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:03:22 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: That's also a good idea too. Though I think maybe safer to say: <*NT386:callingconvention push*><*NT386:callingconvention winapi*> ..bunch of decls .. <*NT386:callingconvention pop*> > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI. Tony, is /everything/ Win32 ugly? :) The status of SQLHWND is less clear to me now, seems I have trouble with the basic find-in-files.. Even so -- it used like once, its type is almost the same, the Windef definition is now available, the headers are almost the same. I did notice the Win32 headers actually #ifdef: #if defined(WIN32) || defined(OS2)typedef HWND SQLHWND;#elif defined (UNIX)typedef Widget SQLHWND;#else/* placehold for future O/S GUI window handle definition */typedef SQLPOINTER SQLHWND;#endif Might be nice to have a limited form of #if in Modula-3. I understand -- don't want to have to parse headers over and over. Maybe only if on TARGET and nothing else? Slippery slope. So far ODBC is the main place I've seen this and I'm just about over it. The status of OpenGL here isn't clear, seems maybe the opposite -- __stdcall on NT386, __cdecl on NT386GNU. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> Date: Mon, 11 Feb 2008 11:26:50 -0500> To: jayk123 at hotmail.com> > Why not simply default EXTERNAL on Win32 to WINAPI instead? That > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI.> > On Feb 11, 2008, at 5:13 AM, Jay wrote:> > > I know this won't be popular but...> >> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> >> > The differences are> >> > the UNUSED type SQLHWND is ADDRESS or HWND> > This should just be removed.> >> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> >> > For this and other reasons, I suggest that all CM3 frontends accept > > but silently> > ignore the Win32/x86 calling conventions in <*external*> pragmas,> > similar to what the non-x86 Windows compilers do.> >> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> >> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.> > It is a small safe change that will allow a little more Modula-3 > > source portability.> >> > A similar suggestion would be to change the default calling > > convention in Modula-3,> > it would very possibly reduce code size, but is very very very much > > a breaking> > change so probably can never happen.> > Better probably would be to a) add a switch for this b) extend > > the .m3exports> > or whatnot files to indicate what switch was used.> >> > A "blanket pragma" might also be good, so that the various *.i3 > > files can> > say just to assume __stdcall for the rest of the file instead of > > annotating each functions.> >> > - Jay> >> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:04:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:04:10 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Sorry. They belong in Cstddef.i3. size_t is already there. Let's try to stick to the C ".h" structure. size_t = INTEGER. On Feb 11, 2008, at 4:51 PM, Jay wrote: > > These are OS-dependent! They should not be in BasicCtypes. > > 1) There is no Utypes on Windows. > These are very basic types that belong at a very low level. > In C++ for example, size_t is provided "automatically" by the > compiler, no header is needed. > > 2) Are they really OS dependent? What OS makes my definitions wrong? > On what 32 bit architecture is size_t not an unsigned 32 bit > integer and ptrdiff_t not a signed 32 bit integer? > Ditto for 64 bit. > These should always be the same size as a pointer and with the > proper signedness. > Even if some of the *.i3 files make size_t = int, is that really > correct? > And, I assume int vs. long issue is not an issue here. > Though they may be different types in C and C++, they need not be > in Modula-3 (when they are the same size, of course) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > To: jayk123 at hotmail.com > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > > INTEGER; > > > > > > really? it is signed? > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > That has a 32 bit and 64 bit version, at least. > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 11 23:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:34:27 +0000 Subject: [M3devel] size_t? In-Reply-To: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: I did later notice size_t was there. I think what I earlier noticed was ptrdiff_t nowhere. > size_t = INTEGER. But unsigned presumably? What I had was correct, right? In C++ no header is needed for size_t, it is just so basic and widespread. Not sure about ptrdiff_t. Either way, they both do live in that middle ground between compiler and library -- a very low level -- as size_t is defined as the type of sizeof() expressions and ptrdiff_t is defined as the type you get when you subtract pointers. And you don't need nay header to use sizeof() or subtract pointers. If it were really up to me, I'd have the Modula-3 language predefine all of int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. There is a corralary dilemna here that I haven't figured out, and have seen code address that I haven't adjusted to yet. That is, the code uses uint32 "everywhere", instead of something "more abstract/vague". When it comes down to it, I suspect this is the right thing. The abstraction only seems to buy problems. UNLESS you have a processor with a larger natural integer that performs poorly on smaller integers, or a processor that perfs badly with 32 bit integers. Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. In many and growing systems, "int", besides its signedness, is too small for many occurences. That is the problem I think in C. If Modula-3 has essentially defined INTEGER to be the size of a pointer, then ok. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 17:04:10 -0500> To: jayk123 at hotmail.com> > Sorry.> > They belong in Cstddef.i3. size_t is already there. Let's try to > stick to the C ".h" structure.> > size_t = INTEGER.> > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > > > These are OS-dependent! They should not be in BasicCtypes.> >> > 1) There is no Utypes on Windows.> > These are very basic types that belong at a very low level.> > In C++ for example, size_t is provided "automatically" by the > > compiler, no header is needed.> >> > 2) Are they really OS dependent? What OS makes my definitions wrong?> > On what 32 bit architecture is size_t not an unsigned 32 bit > > integer and ptrdiff_t not a signed 32 bit integer?> > Ditto for 64 bit.> > These should always be the same size as a pointer and with the > > proper signedness.> > Even if some of the *.i3 files make size_t = int, is that really > > correct?> > And, I assume int vs. long issue is not an issue here.> > Though they may be different types in C and C++, they need not be > > in Modula-3 (when they are the same size, of course)> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > To: jayk123 at hotmail.com> > >> > >> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > >> > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t => > > > INTEGER;> > > >> > > > really? it is signed?> > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > >> > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > That has a 32 bit and 64 bit version, at least.> > >> > > These are OS-dependent! They should not be in BasicCtypes.> > >> > > >> > > >> > > > Does INTEGER effectively equal int or ptrdiff_t?> > > >> > > > - Jay> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:40:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:40:44 -0500 Subject: [M3devel] external in module? In-Reply-To: <1202765600.8543.32.camel@faramir.m3w.org> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> <1202765600.8543.32.camel@faramir.m3w.org> Message-ID: Not sure... On Feb 11, 2008, at 4:33 PM, Dragi?a Duri? wrote: > But... We DO HAVE dynamic loading, and it's not altogether unlike > Java :). > > Did these patches of mine made to CM3 HEAD? > > dd > > On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: >> This would be a bigger issue if we had dynamic loading like Java. To >> some degree, m3makefile imports give us some protection against name >> clashes. But, I do see your point that a name clash may prevent >> reuse of separately developed packages. >> >> On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> Please -- no hierarchical namespaces. Ultimately, they need a >>>> definitive hierarchy anyway. >>> >>> I wasn't going to write the code, so no need to worry. >>> However, if this is not the solution we aim at, then we need to >>> do something else about the increasing probability of the builder >>> failing because some module in a completely different package >>> which I don't even use directly happens to have the same name >>> as my internal module and thus cannot be compiled. Or even worse: >>> if I use two packages that happen to contain one module of the >>> same name and have never been used together before. >>> >>> Olaf >>> >>> PS: This reminds me of Leslie Lamports definition of distributed >>> computing: when a computer you didn't even know existed >>> can render your own computer unusable :) >>> >>>> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >>>> >>>>> Quoting Jay : >>>>> >>>>>> It'd be nice if I could declare externals in modules. >>>>>> In this example, setitimer_ only exists for the wrapper >>>>>> implementation. >>>>>> I don't need it to be visible outside the one module that uses >>>>>> it. >>>>>> I guess I could push it into an unexposed interface, even >>>>>> dedicate "internal.i3" to it?Is that an ok idiom? >>>>> >>>>> Yes, use an internal interface of the package. But you should use >>>>> another name (something longer and more unique), since the CM3 >>>>> builder still has problems with multiple defined units AFAIK. >>>>> >>>>> This is something that should really be fixed, but that's another >>>>> topic. (We'd need hierarchical name spaces, but introduce them in >>>>> a compatible way.) >>>>> >>>>> Olaf >>>>> >>>>>> It's another problem that I don't know what to call these >>>>>> things.. >>>>> >>>>> This usually is _my_ problem :-) >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>> 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>> Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Feb 12 00:37:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 18:37:56 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. Subtracting two pointers yields ptrdiff_t, so in M3 it would presumably be INTEGER. size_t is what sizeof returns, so I imagine size_t=CARDINAL is probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should better be Word.T to match C's unsigned interpretation. Of course, Word.T is simply INTEGER anyway in the current CM3 implementation. Note that neither of these need to be defined in the 32bit/64bit subdirectories since they are straightforwardly the same as the underlying word size. On Feb 11, 2008, at 5:34 PM, Jay wrote: > I did later notice size_t was there. > I think what I earlier noticed was ptrdiff_t nowhere. > > > size_t = INTEGER. > > But unsigned presumably? > > What I had was correct, right? > In C++ no header is needed for size_t, it is just so basic and > widespread. > Not sure about ptrdiff_t. > > Either way, they both do live in that middle ground between > compiler and library -- a very low level -- > as size_t is defined as the type of sizeof() expressions and > ptrdiff_t is defined as the type you get when you subtract > pointers. And you don't need nay header to use sizeof() or subtract > pointers. > > If it were really up to me, I'd have the Modula-3 language > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > There is a corralary dilemna here that I haven't figured out, and > have seen code address that I haven't adjusted to yet. That is, the > code uses uint32 "everywhere", instead of something "more abstract/ > vague". When it comes down to it, I suspect this is the right > thing. The abstraction only seems to buy problems. UNLESS you have > a processor with a larger natural integer that performs poorly on > smaller integers, or a processor that perfs badly with 32 bit > integers. > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > In many and growing systems, "int", besides its signedness, is too > small for many occurences. > That is the problem I think in C. If Modula-3 has essentially > defined INTEGER to be the size of a pointer, then ok. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > To: jayk123 at hotmail.com > > > > Sorry. > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > stick to the C ".h" structure. > > > > size_t = INTEGER. > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > 1) There is no Utypes on Windows. > > > These are very basic types that belong at a very low level. > > > In C++ for example, size_t is provided "automatically" by the > > > compiler, no header is needed. > > > > > > 2) Are they really OS dependent? What OS makes my definitions > wrong? > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > integer and ptrdiff_t not a signed 32 bit integer? > > > Ditto for 64 bit. > > > These should always be the same size as a pointer and with the > > > proper signedness. > > > Even if some of the *.i3 files make size_t = int, is that really > > > correct? > > > And, I assume int vs. long issue is not an issue here. > > > Though they may be different types in C and C++, they need not be > > > in Modula-3 (when they are the same size, of course) > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > size_t = > > > > > INTEGER; > > > > > > > > > > really? it is signed? > > > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > - Jay > > > > > > Need to know the score, the latest news, or you need your > Hotmail?- > > > get your "fix". Check it out. > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Tue Feb 12 02:05:39 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:05:39 +0000 Subject: [M3devel] size_t? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: I think ANSI C is a bit of a mess here. For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... Anyway.. But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. For example, strlen returns size_t, so #include must define it (directly or indirectly). Malloc takes size_t, so #include must define it (directly or indirectly). fread/fwrite/stdio.h ditto. I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). Pushing some things into fewer larger integers is a step in this direction. It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. So maybe just size_t is missing? I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? Good enough? Really, I'm sure you have all figured out, I want Modula-3 to look more like C. :) The more I use C lately (as opposed to C++) and the more I use Modula-3 lately..the more I find C perfectly ok, the unsafety easy enough to not be bitten by, the more the heap allocations and copying that "safety" cost seem not worth it.. It's an interesting system largely just because it is yet another system, in need (arguably) of more targets, and where "NT386" exists but gets little support. Someone who "likes" Modula-3 more would serve it better than me, perhaps. But I'm here. :) I also like that a decent module system was worked out such as to build fast, at least when using the integrated backend. So maybe I just write all my Modula-3 as "unsafe" and be happy. :) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 18:37:56 -0500> To: jayk123 at hotmail.com> > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h.> > Subtracting two pointers yields ptrdiff_t, so in M3 it would > presumably be INTEGER.> size_t is what sizeof returns, so I imagine size_t=CARDINAL is > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > better be Word.T to match C's unsigned interpretation. Of course, > Word.T is simply INTEGER anyway in the current CM3 implementation. > Note that neither of these need to be defined in the 32bit/64bit > subdirectories since they are straightforwardly the same as the > underlying word size.> > On Feb 11, 2008, at 5:34 PM, Jay wrote:> > > I did later notice size_t was there.> > I think what I earlier noticed was ptrdiff_t nowhere.> >> > > size_t = INTEGER.> >> > But unsigned presumably?> >> > What I had was correct, right?> > In C++ no header is needed for size_t, it is just so basic and > > widespread.> > Not sure about ptrdiff_t.> >> > Either way, they both do live in that middle ground between > > compiler and library -- a very low level --> > as size_t is defined as the type of sizeof() expressions and > > ptrdiff_t is defined as the type you get when you subtract > > pointers. And you don't need nay header to use sizeof() or subtract > > pointers.> >> > If it were really up to me, I'd have the Modula-3 language > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER.> > There is a corralary dilemna here that I haven't figured out, and > > have seen code address that I haven't adjusted to yet. That is, the > > code uses uint32 "everywhere", instead of something "more abstract/ > > vague". When it comes down to it, I suspect this is the right > > thing. The abstraction only seems to buy problems. UNLESS you have > > a processor with a larger natural integer that performs poorly on > > smaller integers, or a processor that perfs badly with 32 bit > > integers.> >> > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t.> > In many and growing systems, "int", besides its signedness, is too > > small for many occurences.> > That is the problem I think in C. If Modula-3 has essentially > > defined INTEGER to be the size of a pointer, then ok.> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 17:04:10 -0500> > > To: jayk123 at hotmail.com> > >> > > Sorry.> > >> > > They belong in Cstddef.i3. size_t is already there. Let's try to> > > stick to the C ".h" structure.> > >> > > size_t = INTEGER.> > >> > > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > >> > > > 1) There is no Utypes on Windows.> > > > These are very basic types that belong at a very low level.> > > > In C++ for example, size_t is provided "automatically" by the> > > > compiler, no header is needed.> > > >> > > > 2) Are they really OS dependent? What OS makes my definitions > > wrong?> > > > On what 32 bit architecture is size_t not an unsigned 32 bit> > > > integer and ptrdiff_t not a signed 32 bit integer?> > > > Ditto for 64 bit.> > > > These should always be the same size as a pointer and with the> > > > proper signedness.> > > > Even if some of the *.i3 files make size_t = int, is that really> > > > correct?> > > > And, I assume int vs. long issue is not an issue here.> > > > Though they may be different types in C and C++, they need not be> > > > in Modula-3 (when they are the same size, of course)> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] size_t?> > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > >> > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > > >> > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > size_t => > > > > > INTEGER;> > > > > >> > > > > > really? it is signed?> > > > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > > > >> > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > > > That has a 32 bit and 64 bit version, at least.> > > > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > > >> > > > > >> > > > > >> > > > > > Does INTEGER effectively equal int or ptrdiff_t?> > > > > >> > > > > > - Jay> > > >> > > > Need to know the score, the latest news, or you need your > > Hotmail?-> > > > get your "fix". Check it out.> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 02:21:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:21:24 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86. __clrcall sort of doesn't count. It really must means "managed code", using the only calling convention available. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Feb 12 02:29:12 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:29:12 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47AF72B5.2080308@wichita.edu> References: <47AF72B5.2080308@wichita.edu> Message-ID: The liberalised alignment rules are required for the native Mac OS X API and should stay. You cannot use that API without them. I think the pragma is not required and can be removed. I agree with all the points you make. The effect of the modified alignment rules it to allow *packed* structures to have members aligned on byte boundaries. This has the effect of packing the fields in the tightest arrangement allowed by the platform. This might affect performance, but if the user is concerned about this they should specify field bit sizes that deliver improved performance. I don't see a need to specify this on a structure level, for the reasons you give and because the difference isn't significant enough in the case of packed structures and their physical layout and restrictions are platform dependent anyway. I might also add that the alignment code is currently broken on I386_DARWIN. - Darko On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > Does anybody know about the status of pragma <*LAZYALIGN*>? Is it > being used anywhere? > > It is not documented in pragmas.html. The compiler front end appears > to accept it. (In fact, Decls.m3 contains constants that suggest > limitations on what declarations the pragma can appear on, but these > are not actually enforced.) It liberalizes the alignment rules, > generally allowing scalars to start on any byte boundary. > > Pickles have to be able to reconstruct the layout of types as the > compiler would have done it for a machine (on which a now-being-read > pickle was written) with different word size and alignment properties. > Currently, pickles are completely unaware of lazy alignment. It > would have to be encoded in type descriptions generated by the > compiler > using TipeDesc and read by pickles using RTTipe. > > Most troubling to me is what looks like a linguistic Pandora's box. > The pragma can be associated with any constant, variable, or type > _declaration_ (not type definition), with the result that different > values of the same type can actually be different in their alignment > rules and thus their layout. Similarly for different identifiers > equated to the same type. Although the effects of this could possibly > be hidden from the programmer in purely safe code, not so with unsafe > code. I haven't thoroughly thought this through, but seems to me to > really fly in the face of the whole typing philosophy of the language. > > For example, if pickles were to read in an object value, and there > were >1 variants of the object's type in the reading program, > differing > only in the alignment rules, how would it decide which one to build? > In fact, ignoring pickles altogether and just looking at a single > program, > if the object's type doesn't actually uniquely give its memory layout, > how can it be accessed correctly? > > Additionally, a quick look at the compiler suggests it won't generate > correct code for whole record assignment when the LHS and RHS are the > same type but have different alignment characteristics. > > The more I think about it, it seems the only workable possibilities > are: > > 1) Require the pragma to be associated only with a type _definition_ > not a > declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > this a > property of the type that propagates to all names for the type and > all variables, constants, etc. Also, this would make this property > a part of the type signature that pickles uses when reading, -OR- > > 2) Forget it altogether. > > What do people think? > -- > ------------------------------------------------------------- > 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 darko at darko.org Tue Feb 12 02:37:49 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:37:49 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> I think it's not a good idea. I think all platform specific code should be in a separate file. I'd also like to see an option to move calling conventions to the makefile rather than in pramas to avoid having to duplicate interface files just to have a different calling convention for a different platform. - Darko On 12/02/2008, at 12:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew > more lower level details and playing games with calling conventions > was something anyone could do. Most other current systems are rooted > in C programming. Working in C, calling conventions are generally in > a hidden layer below what anyone thinks about. Therefore, the > smaller number of capable people working at that level have the good > sense to only have one calling convention. No more systems will > evolve from "small", at least not without having observed this > history. Therefore, there will no longer be multiple calling > conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:07:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:07:04 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So, here's the thing about pragmas. According to the language definition, they can be ignored and the program should still "mean" the same thing. Preprocessing definitely does not fit that model. On Feb 11, 2008, at 8:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc > directory and bringing up ignoring WINAPI on non-NT386 or prefixing > calling conventions with a target. > > This reminds me of an important point here however -- nobody else > is going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from > "small" systems, where assembly programming was common, more people > knew more lower level details and playing games with calling > conventions was something anyone could do. Most other current > systems are rooted in C programming. Working in C, calling > conventions are generally in a hidden layer below what anyone > thinks about. Therefore, the smaller number of capable people > working at that level have the good sense to only have one calling > convention. No more systems will evolve from "small", at least not > without having observed this history. Therefore, there will no > longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:08:27 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:27 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <65396937-761B-4CA3-A20F-A04D53FAA6D2@cs.purdue.edu> C and Modula-3 fill different needs. I use C when it makes sense. I use Modula-3 when it makes sense. I'd hate to blur the distinction between them though! On Feb 11, 2008, at 8:05 PM, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. > That is good. Each header exposes certain names and few names are > exposed by more than one header. As well, for good measure, your > own #includes of ANSI C headers I believe is speced as order- > independent. These are all aspects of a "good module system", > except this solid foundation is built on a foundation of quicksand > and there is inadequate support for it in the language -- i.e. no > static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from > multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must > define it (directly or indirectly). > Malloc takes size_t, so #include must define it > (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing > all of stddef.h however. > IF NOT, then there must be some underlying implementation defined > layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is > probably usually a bad idea, but it can also be darn convenient. > Just #include everything, and have everything available in the > global namespace. > The "language" does live in this space. INTEGER is ALWAYS available > and always has the same meaning (per-target). I cannot redefine it > (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this > direction. > It breaks "modularity" and so should be done very selectively, but / > arguably/ size_t and ptrdiff_t are fundamental enough to warrant > such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be > in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on > all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? > > Really, I'm sure you have all figured out, I want Modula-3 to look > more like C. :) > The more I use C lately (as opposed to C++) and the more I use > Modula-3 lately..the more I find C perfectly ok, the unsafety easy > enough to not be bitten by, the more the heap allocations and > copying that "safety" cost seem not worth it.. > > It's an interesting system largely just because it is yet another > system, in need (arguably) of more targets, and where "NT386" > exists but gets little support. Someone who "likes" Modula-3 more > would serve it better than me, perhaps. But I'm here. :) > > I also like that a decent module system was worked out such as to > build fast, at least when using the integrated backend. > So maybe I just write all my Modula-3 as "unsafe" and be happy. :) > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 18:37:56 -0500 > > To: jayk123 at hotmail.com > > > > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. > > > > Subtracting two pointers yields ptrdiff_t, so in M3 it would > > presumably be INTEGER. > > size_t is what sizeof returns, so I imagine size_t=CARDINAL is > > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > > better be Word.T to match C's unsigned interpretation. Of course, > > Word.T is simply INTEGER anyway in the current CM3 implementation. > > Note that neither of these need to be defined in the 32bit/64bit > > subdirectories since they are straightforwardly the same as the > > underlying word size. > > > > On Feb 11, 2008, at 5:34 PM, Jay wrote: > > > > > I did later notice size_t was there. > > > I think what I earlier noticed was ptrdiff_t nowhere. > > > > > > > size_t = INTEGER. > > > > > > But unsigned presumably? > > > > > > What I had was correct, right? > > > In C++ no header is needed for size_t, it is just so basic and > > > widespread. > > > Not sure about ptrdiff_t. > > > > > > Either way, they both do live in that middle ground between > > > compiler and library -- a very low level -- > > > as size_t is defined as the type of sizeof() expressions and > > > ptrdiff_t is defined as the type you get when you subtract > > > pointers. And you don't need nay header to use sizeof() or > subtract > > > pointers. > > > > > > If it were really up to me, I'd have the Modula-3 language > > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > > > There is a corralary dilemna here that I haven't figured out, and > > > have seen code address that I haven't adjusted to yet. That is, > the > > > code uses uint32 "everywhere", instead of something "more > abstract/ > > > vague". When it comes down to it, I suspect this is the right > > > thing. The abstraction only seems to buy problems. UNLESS you have > > > a processor with a larger natural integer that performs poorly on > > > smaller integers, or a processor that perfs badly with 32 bit > > > integers. > > > > > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > > > In many and growing systems, "int", besides its signedness, is too > > > small for many occurences. > > > That is the problem I think in C. If Modula-3 has essentially > > > defined INTEGER to be the size of a pointer, then ok. > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Sorry. > > > > > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > > > stick to the C ".h" structure. > > > > > > > > size_t = INTEGER. > > > > > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > 1) There is no Utypes on Windows. > > > > > These are very basic types that belong at a very low level. > > > > > In C++ for example, size_t is provided "automatically" by the > > > > > compiler, no header is needed. > > > > > > > > > > 2) Are they really OS dependent? What OS makes my definitions > > > wrong? > > > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > > > integer and ptrdiff_t not a signed 32 bit integer? > > > > > Ditto for 64 bit. > > > > > These should always be the same size as a pointer and with the > > > > > proper signedness. > > > > > Even if some of the *.i3 files make size_t = int, is that > really > > > > > correct? > > > > > And, I assume int vs. long issue is not an issue here. > > > > > Though they may be different types in C and C++, they need > not be > > > > > in Modula-3 (when they are the same size, of course) > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: [M3devel] size_t? > > > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > > size_t = > > > > > > > INTEGER; > > > > > > > > > > > > > > really? it is signed? > > > > > > > and we are sure this is going to be 64 bits on 64 bit > targets? > > > > > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > > > > > - Jay > > > > > > > > > > Need to know the score, the latest news, or you need your > > > Hotmail?- > > > > > get your "fix". Check it out. > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Tue Feb 12 03:08:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:46 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> Message-ID: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Indeed! On Feb 11, 2008, at 8:37 PM, Darko wrote: > I think it's not a good idea. I think all platform specific code > should be in a separate file. I'd also like to see an option to > move calling conventions to the makefile rather than in pramas to > avoid having to duplicate interface files just to have a different > calling convention for a different platform. > > - Darko > > > On 12/02/2008, at 12:21 PM, Jay wrote: > >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, >> or an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in >> an interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, >> just sending out the bait... >> >> Obviously this was triggered by my happening into the odbc >> directory and bringing up ignoring WINAPI on non-NT386 or >> prefixing calling conventions with a target. >> >> This reminds me of an important point here however -- nobody else >> is going to make the mistake of ever having multiple calling >> conventions. Therefore the generality of prefixing WINAPI with >> NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from >> "small" systems, where assembly programming was common, more >> people knew more lower level details and playing games with >> calling conventions was something anyone could do. Most other >> current systems are rooted in C programming. Working in C, calling >> conventions are generally in a hidden layer below what anyone >> thinks about. Therefore, the smaller number of capable people >> working at that level have the good sense to only have one calling >> convention. No more systems will evolve from "small", at least not >> without having observed this history. Therefore, there will no >> longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 From rodney.bates at wichita.edu Tue Feb 12 05:17:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 11 Feb 2008 22:17:13 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: <47B11DC9.1040902@wichita.edu> I don't think this is what Tony meant. In C++, an opening brace starts a block, but every local declaration in that block has its own unique scope that only starts at that declaration and goes to the end of the block. This is particularly messy because the local declarations of a block need not all precede all the statements, and even worse because the distinction between declarations and statements is extremely subtle and, unless things have changed, never actually defined. (Do you remember Stroustrup's famous quote when taken to task about this? "If it looks like a declaration, it's a declaration. If it looks like a statement, it's a statement. If it doesn't look like either, it's a syntax error.") In contrast, in Modula-3, the scope of every local declaration starts at the beginning of the block and ends at the end of the block. The C++ reference makes an attempt at defining different terms for the entire block and the region where the identifier can be referred-to, i.e., from declaration to end of block (which I have called "scope" here). But as I recall, they ended up carefully defining their terminology in one section but then not using it consistently in the rest of the language definition. One of the few things Ada did better than Modula-3 was that the syntax has an explicit delimiter at all three relevant points: beginning of block, between declarations and statements, and end of block. (But it still has C++-like scopes for every declaration>.) I am an adamant believer in a high level of syntactic explicitness. Ada Modula-3 C++ start of block: DECLARE { between decls and stmts: BEGIN BEGIN end of block: END END } Jay wrote: > If you want a precise scope in C++, just but in an opening brace. > Just like how in Modula-3 (now I know) you can have "BEGIN" almost > anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. > It isn't often used though, granted. > > - Jay > > ------------------------------------------------------------------------ > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] introducing VAR in more places? > > Date: Mon, 11 Feb 2008 11:34:54 -0500 > > To: jayk123 at hotmail.com > > > > You can, except you need to explicitly give the block scope: > > > > VAR ... > > BEGIN > > ... > > END; > > > > I find this much better than C++ where the scope of the new variable > > is imprecisely defined. > > > > On Feb 11, 2008, at 4:29 AM, Jay wrote: > > > > > Does anyone else find it bothersome that you can't introduce VARs > > > anywhere? Kind of like in C++? > > > Ok, or if you grant that frame size doesn't matter THAT much, and > > > the compiler might do stack packing anyway, you can move all your > > > locals up top like typical C, but still, how about for the module > > > initializer? > > > Still it seems good to me to do manual stack packing since it is > > > often so easy.. > > > WITH helps, but only for "relative constants". > > > > > > It would be nice if the code below could have still loops until t0 ! > > > = t1, but the repeat condition is outside the scope in which t1 is > > > available. This feels quite lame.. > > > > > > - Jay > > > > > > > > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > > To: m3commit at elegosoft.com > > > > From: jkrell at elego.de > > > > Subject: [M3commit] CVS Update: cm3 > > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > > > Modified files: > > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message: > > > > no need for globals here.. > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > ------------------------------------------------------------------------ > Connect and share in new ways with Windows Live. Get it now! > -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Tue Feb 12 05:10:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:10:20 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <427855DD-C178-414E-8AEC-3BB723699B87@cs.purdue.edu> Score a big win for the regression test framework! I would not have devoted the time to finding the recently fixed race condition for mutex/condition initialization in the pthreads-based thread implementation if I had not been told about the problem with p007 on FreeBSD4. The problem only revealed itself in a repeatable way on FreeBSD4, and not repeatably enough to be debuggable on all the other systems I use (I386_DARWIN, PPC_DARWIN, LINUXLIBC6, or Solaris -- except for a clue in an error report from Alex Bochanek). Regression testing on multiple platforms is practically the only way to shake out these sorts of insidious bugs. Yay! Good work guys! On Jan 31, 2008, at 6:43 AM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression >> testing >> would help and should be introduced. Tests should be run daily/ >> nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these >> services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for > others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be > transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a > FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of > course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to > participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh > cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment > this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox /usr/ > local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue Feb 12 05:27:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:27:35 -0500 Subject: [M3devel] scripts/PKGS Message-ID: I notice scripts/PKGS is no longer in the repository. Does this get generated somehow now? I know that do-cm3-std.sh depends on it because my copy of PKGS was broken (missing sysutils). Can someone explain to me how the build scripts have changed and how I should be using them? From darko at darko.org Tue Feb 12 05:37:52 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 15:37:52 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B1168F.8020302@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> Message-ID: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for historical reasons. All other structures should use normal alignment to be compatible with C and Unix interfaces. The alignment change was implemented to be supported only in packed structures as a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly restrictive alignment rules in packed structures. On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > It sounds like all that Mac OS X needs is for _all_ types in an entire > program to use the liberal packing rules. Have I understood > correctly? > I would have no grief over that. > > Darko wrote: >> The liberalised alignment rules are required for the native Mac OS >> X API and should stay. You cannot use that API without them. I >> think the pragma is not required and can be removed. I agree with >> all the points you make. The effect of the modified alignment >> rules it to allow *packed* structures to have members aligned on >> byte boundaries. This has the effect of packing the fields in the >> tightest arrangement allowed by the platform. This might affect >> performance, but if the user is concerned about this they should >> specify field bit sizes that deliver improved performance. I don't >> see a need to specify this on a structure level, for the reasons >> you give and because the difference isn't significant enough in >> the case of packed structures and their physical layout and >> restrictions are platform dependent anyway. >> I might also add that the alignment code is currently broken on >> I386_DARWIN. >> - Darko >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>> being used anywhere? >>> >>> It is not documented in pragmas.html. The compiler front end >>> appears >>> to accept it. (In fact, Decls.m3 contains constants that suggest >>> limitations on what declarations the pragma can appear on, but these >>> are not actually enforced.) It liberalizes the alignment rules, >>> generally allowing scalars to start on any byte boundary. >>> >>> Pickles have to be able to reconstruct the layout of types as the >>> compiler would have done it for a machine (on which a now-being-read >>> pickle was written) with different word size and alignment >>> properties. >>> Currently, pickles are completely unaware of lazy alignment. It >>> would have to be encoded in type descriptions generated by the >>> compiler >>> using TipeDesc and read by pickles using RTTipe. >>> >>> Most troubling to me is what looks like a linguistic Pandora's box. >>> The pragma can be associated with any constant, variable, or type >>> _declaration_ (not type definition), with the result that different >>> values of the same type can actually be different in their alignment >>> rules and thus their layout. Similarly for different identifiers >>> equated to the same type. Although the effects of this could >>> possibly >>> be hidden from the programmer in purely safe code, not so with >>> unsafe >>> code. I haven't thoroughly thought this through, but seems to me >>> to >>> really fly in the face of the whole typing philosophy of the >>> language. >>> >>> For example, if pickles were to read in an object value, and there >>> were >1 variants of the object's type in the reading program, >>> differing >>> only in the alignment rules, how would it decide which one to build? >>> In fact, ignoring pickles altogether and just looking at a single >>> program, >>> if the object's type doesn't actually uniquely give its memory >>> layout, >>> how can it be accessed correctly? >>> >>> Additionally, a quick look at the compiler suggests it won't >>> generate >>> correct code for whole record assignment when the LHS and RHS are >>> the >>> same type but have different alignment characteristics. >>> >>> The more I think about it, it seems the only workable >>> possibilities are: >>> >>> 1) Require the pragma to be associated only with a type >>> _definition_ not a >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>> this a >>> property of the type that propagates to all names for the type and >>> all variables, constants, etc. Also, this would make this property >>> a part of the type signature that pickles uses when reading, -OR- >>> >>> 2) Forget it altogether. >>> >>> What do people think? >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 hendrik at topoi.pooq.com Tue Feb 12 05:35:55 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:35:55 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <20080212043555.GA21429@topoi.pooq.com> On Tue, Feb 12, 2008 at 01:05:39AM +0000, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must define it (directly or indirectly). > Malloc takes size_t, so #include must define it (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. > IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. > The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this direction. > It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? The real requirement on size_t is that values of that type can be used freely in address arithmetic. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:38:21 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:38:21 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080212043821.GB21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:03:22PM +0000, Jay wrote: > Tony, is /everything/ Win32 ugly? :) No. Some of the video games are breathtakingly beautiful. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:39:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:39:29 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: <20080212043929.GC21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 09:52:06PM +0000, Jay wrote: > I guess I should switch the default calling convention and see what > the code size difference is. > Yes. Code size can be neasured. -- hendrik From jayk123 at hotmail.com Tue Feb 12 07:16:45 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:16:45 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: It is generated if it doesn't exist. Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them?> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:18:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:18:01 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: <20080212042047.A12E210D4686@birch.elegosoft.com> References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I added some files a while ago and someone either complained or added them, so I've been adding them since. - Jay > Date: Tue, 12 Feb 2008 05:20:47 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:20:47> > Modified files:> cm3/m3-sys/cm3/src/: m3makefile > > Log message:> Let's avoid RCS id stuff shall we. Just clutters up the files...> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:22:28 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:22:28 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available. There is/was a compilation problem with what I was doing. I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 08:20:33 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 07:20:33 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: This is not my doing, at least not knowingly, just reporting the facts, officer. I wonder if maybe something more like Randy's scheme should be put in place. He has a smaller hand authored checked in file. The current system is more automatic, but doesn't handle changes automatically, and generates far more data than necessary I think. Perhaps another approach is to keep a timestamp/revision, embedded in the name, pkgs.v1234, someone rev the name as needed, and if the desired name doesn't exist rm pkgs.v* and recreate? This is a nice simple model imho. Changes are also very infrequent in my short observance. (I do go so far in the python directory to always use forward slashes, so the files are more portable across systems. :) Really, you know, it doesn't matter what the underlying system uses, as long as you translate at all the appropriate places and as long as you pick a syntax that can represent everything needed (not necessarily anything the underlying system supports). However you do have to translate at all the appropriate levels, possibly under the guidance of user settings. In particular, I can set M3CONFIG, M3ROOT, etc. to have forward slashes and it works just fine on Windows, but when errors are reported with paths, I can't paste them into file.open dialogs without changing the slashes....) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 06:16:45 +0000Subject: Re: [M3devel] scripts/PKGS It is generated if it doesn't exist.Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them? _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 09:16:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 09:16:42 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken Message-ID: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Tonight some of the tinderbox builds failed for CM3. First I thought it was just these changes to FilePosix which had already been fixed: ---------------------------- revision 1.8 date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: +1 -1; commitid: pvCLLyqdDKQm24Rs; This checkin fixes something Jay left behind. Please check things build on platforms other than yours before making changes. The VAL is necessary on some targets because 0 is INTEGER whereas result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly compared with an INTEGER (result). The VAL is how we do the conversion to LONGINT. On platforms where Utypes.off_t is INTEGER this code will work the same as it is. ---------------------------- revision 1.7 date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: +1 -1; commitid: j3ewJLumr87rqWQs; more cygwin header cleanup, various dead types were used in further dead types in Ushm.i3; go ahead and delete dead stuff instead of commenting out remove seemingly unnecessary VAL() that fails to compile but when I try to build now on my FreeBSD system, I get this from cm3: % ./m3-sys/cm3/FreeBSD4/cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 *** ^C Please check all the latest commits carefully and back out anything that seems suspicious or has not been tested. Thanks, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Feb 12 09:27:40 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:27:40 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: drat...I'd like to punt just a few hours here and will get to it then. Sorry. I hardly changed anything "live" other than what Tony put back. Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 09:45:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:45:24 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: The only other non-NT386/GNU change by me, from a quick scan of ChangeLog, is: 2008-02-10 23:24 jkrell * m3-libs/m3core/src/: runtime/m3makefile, thread/m3makefile, thread/Common/SchedulerPosix.i3, thread/Common/m3makefile, thread/POSIX/SchedulerPosix.i3, thread/POSIX/m3makefile, thread/PTHREAD/SchedulerPosix.i3, thread/PTHREAD/m3makefile, thread/WIN32/ThreadWin32.m3: cheat just a tad and provide SchedulePosix interface on Win32 albeit not a good implementation currently this way NT386GNU can build with Win32 threads and cm3 gets as far as printing an error and exiting, probably something to do with pesky slashes; a lot better than hanging due to nanosleep failing and worrying about a lot of non trivial cygwin code.. which looks very ok. I moved SchedulerPosix to common and provided a do-nothing implementation for NT386. This is so NT386GNU can use native Win32 threads, but Posix in other places like i/o. (Sometimes I wonder...maybe all that's needed is handling forward and backward slashes the same c:/foo/bar, which I already put in, plus allowing X Windows... (Trestle builds now btw...std packages get at least as far as anim3d. Running stuff is known to have problems..the slash issues were just because I had backslashes (and colons) in paths in environment variables... the current problem is that cm3 always seems to think files are out of date and that all builds fail, but it does actually run cm3cg over everything and seems to work...surely an easy issue to deal with...oh I think m3bundle crashes, the only other thing I've run besides cm3...like..for example, keeping time in seconds since 1970 in a 32bit signed integer seems more like a bug than a feature....maybe I'll start another thread here....even the Win32 Modula-3 interfaces I think use that poor representation, just that they go to the effort of converting from a better format....)) Anyway I'll at least test on birch later and maybe install FreeBSD in a virtual machine..... - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 08:27:40 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken drat...I'd like to punt just a few hours here and will get to it then.Sorry.I hardly changed anything "live" other than what Tony put back.Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 11:34:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 11:34:42 +0100 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Quoting Tony Hosking : > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it because > my copy of PKGS was broken (missing sysutils). Can someone explain to > me how the build scripts have changed and how I should be using them? PKGS has never been checked-in and should not as far as I know. It contains workspace-dependent paths and is built by find-packages.sh if I remember correctly. All shell scripts will generate it if it does not exist. It can be deleted any time, and indeed must be deleted if packages are added (or they will not be found). This is arguably a bug, but then all the scripts were never intended to be a general user interface for CM3 users (only for the maintenance). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Feb 12 12:23:21 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:23:21 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: Obviously if the paths are relative to CM3_ROOT, it isn't workspace dependent... How about my idea of making the name have a "version" in it, and the version can be bumped as needed? Or making it contain relative paths and just maintain it manually? - Jay > Date: Tue, 12 Feb 2008 11:34:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] scripts/PKGS> > Quoting Tony Hosking :> > > I notice scripts/PKGS is no longer in the repository. Does this get> > generated somehow now? I know that do-cm3-std.sh depends on it because> > my copy of PKGS was broken (missing sysutils). Can someone explain to> > me how the build scripts have changed and how I should be using them?> > PKGS has never been checked-in and should not as far as I know.> It contains workspace-dependent paths and is built by find-packages.sh> if I remember correctly. All shell scripts will generate it if it> does not exist. It can be deleted any time, and indeed must be deleted> if packages are added (or they will not be found). This is arguably a bug,> but then all the scripts were never intended to be a general user interface> for CM3 users (only for the maintenance).> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:34:08 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:34:08 +0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: I strongly suggest that at least in some contexts, no padding ever be quietly inserted, and that all seeming need for padding generate an error, unless explicitly quashed, preferably by explicit insertion of padding fields by the programmer, and/or rearrangement sorted by size, or possibly some annotation of the overall struct/record/class/module, an annotation such as <* silent padding ok*>. Alignment issues really bug me... I realize many data structures are only ever seen in memory, by one process, so it doesn't matter, but when it matter, the languages/tools seem to fall down. As well, "padding" fields should be annotated as such and the compiler warn or error if they aren't needed. It's just dumb that code like: struct { int32 a; int64 b;}; when defining some stable important binary layout can have a varying but silently allowed meaning based on command line switches or targets.. Yes, I'm a dumb programmer to write it, but man the tools are lagging. This will fall on deaf ears and far from sufficient ears even if they were hearing. It's the C compilers that are somewhat broken here imho. C is unnecessarily broken here. Imho it's a big cause for headaches and easily solved....it doesn't have to stink so badly, if anyone cared.. I have had to maintain structs that had to look the same across different targets and therefore insert target-dependent padding. Ok, but it should have been easier. When I was done, I put in compile time asserts as to the offset of every single field so the next guy would have an easier time, and assiduously commented every byte of padding in the struct and its target-dependentness.... This was like for shared memory. Grumble, - Jay > From: darko at darko.org> To: rodney.bates at wichita.edu> Date: Tue, 12 Feb 2008 15:37:52 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] <*LAZYALIGN*>> > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures.> > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:> > > It sounds like all that Mac OS X needs is for _all_ types in an entire> > program to use the liberal packing rules. Have I understood > > correctly?> > I would have no grief over that.> >> > Darko wrote:> >> The liberalised alignment rules are required for the native Mac OS > >> X API and should stay. You cannot use that API without them. I > >> think the pragma is not required and can be removed. I agree with > >> all the points you make. The effect of the modified alignment > >> rules it to allow *packed* structures to have members aligned on > >> byte boundaries. This has the effect of packing the fields in the > >> tightest arrangement allowed by the platform. This might affect > >> performance, but if the user is concerned about this they should > >> specify field bit sizes that deliver improved performance. I don't > >> see a need to specify this on a structure level, for the reasons > >> you give and because the difference isn't significant enough in > >> the case of packed structures and their physical layout and > >> restrictions are platform dependent anyway.> >> I might also add that the alignment code is currently broken on > >> I386_DARWIN.> >> - Darko> >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote:> >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it> >>> being used anywhere?> >>>> >>> It is not documented in pragmas.html. The compiler front end > >>> appears> >>> to accept it. (In fact, Decls.m3 contains constants that suggest> >>> limitations on what declarations the pragma can appear on, but these> >>> are not actually enforced.) It liberalizes the alignment rules,> >>> generally allowing scalars to start on any byte boundary.> >>>> >>> Pickles have to be able to reconstruct the layout of types as the> >>> compiler would have done it for a machine (on which a now-being-read> >>> pickle was written) with different word size and alignment > >>> properties.> >>> Currently, pickles are completely unaware of lazy alignment. It> >>> would have to be encoded in type descriptions generated by the > >>> compiler> >>> using TipeDesc and read by pickles using RTTipe.> >>>> >>> Most troubling to me is what looks like a linguistic Pandora's box.> >>> The pragma can be associated with any constant, variable, or type> >>> _declaration_ (not type definition), with the result that different> >>> values of the same type can actually be different in their alignment> >>> rules and thus their layout. Similarly for different identifiers> >>> equated to the same type. Although the effects of this could > >>> possibly> >>> be hidden from the programmer in purely safe code, not so with > >>> unsafe> >>> code. I haven't thoroughly thought this through, but seems to me > >>> to> >>> really fly in the face of the whole typing philosophy of the > >>> language.> >>>> >>> For example, if pickles were to read in an object value, and there> >>> were >1 variants of the object's type in the reading program, > >>> differing> >>> only in the alignment rules, how would it decide which one to build?> >>> In fact, ignoring pickles altogether and just looking at a single > >>> program,> >>> if the object's type doesn't actually uniquely give its memory > >>> layout,> >>> how can it be accessed correctly?> >>>> >>> Additionally, a quick look at the compiler suggests it won't > >>> generate> >>> correct code for whole record assignment when the LHS and RHS are > >>> the> >>> same type but have different alignment characteristics.> >>>> >>> The more I think about it, it seems the only workable > >>> possibilities are:> >>>> >>> 1) Require the pragma to be associated only with a type > >>> _definition_ not a> >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > >>> this a> >>> property of the type that propagates to all names for the type and> >>> all variables, constants, etc. Also, this would make this property> >>> a part of the type signature that pickles uses when reading, -OR-> >>>> >>> 2) Forget it altogether.> >>>> >>> What do people think?> >>> -- > >>> -------------------------------------------------------------> >>> 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> >> > -- > > -------------------------------------------------------------> > 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> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:50:00 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:50:00 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Message-ID: I insist that it depends. Putting every platform-specific piece of code in its own file/directory can lead to mass duplication of nearly identical code. Sometimes an #if here or there goes very far in /improving/ code maintainability. A lot of #if here there and everywhere of course can have the opposite effect. And I realize if you were to drop support for a target, it is easier to find/delete files/directories than #ifs, but I don't think that's a good enough reason to sway the decision. It goes both ways. Yes, you could endeavor factor things down so that everything common is in common, and everything not-common is in platform-specific. But this is inadequate I think. The tail is wagging the dog unnecessarily I think. If my code very nearly all goes together, don't make me separate it. Also sometimes a different factoring is "encouraged" for other reasons, to match someone else's factoring. Look at the C*.i3 files. They actually can be almost all be nearly the same, yet they are hardly shared at all. I realize you could also do a sort of "forwarding", though I'm not sure that Modula-3 offers all the right capabilities for this. Type forwarding, sure. But how about procedure forwarding? Like nt386\cstdio.i3 fopen = common\ccommonstdio.i3 fopen? And having to duplicate a line per type/procedure is lame anyway, you KIND OF want "module inheritance". However, if you allow preprocessing based on target, perhaps the need for that goes away. While extern C varargs functions are generally useless in Modula-3, and therefore extern __cdecl is fairly rare, it DOES occur when you write little helpers in C, such as for errno. A good /heuristic/ might be to change the default in any directory that has no c_source. But it is only heuristic. Whatever is done here, some allowance should probably be made for multiple calling conventions in the same file. Switching the default to the overwhelming majority and then annotating the minority is reasonable. I still believe that silently ignoring calling conventions on all but NT386 is VERY reasonable, and that no other platform from here on out will ever have calling conventions. Esp. not with the same names. When OS/FOO has the FOOAPI calling convention, you can just ignore that one on all but target OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ugly something like: <*EXTERN FOOAPI WINAPI*> fopen(); FOOAPI for OS/FOO, WINAPI ignored. WINAPI for NT386, FOOAPI ignored. The One True Calling Convention for all others, calling convention ignored. I really believe this is highly highly unlikely to occur, and it is not a terrible outcome, and this bridge could be crossed in the far off future. The functions that are usually in need of calling conventions are usually only present on one system. Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly nonexistant. That could be also. A change just for ODBC is probably not the best, though it is a very small safe harmless change (I always say that :) ) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 2008 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform specific code > > should be in a separate file. I'd also like to see an option to > > move calling conventions to the makefile rather than in pramas to > > avoid having to duplicate interface files just to have a different > > calling convention for a different platform.> >> > - Darko> >> >> > On 12/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this through.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good > >> idea.> >>> >> Something like either the ability to prefix pragmas with a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Something like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worms.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expressions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >> etc.> >>> >> I don't really have enough interest here to work through this, > >> just sending out the bait...> >>> >> Obviously this was triggered by my happening into the odbc > >> directory and bringing up ignoring WINAPI on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> This reminds me of an important point here however -- nobody else > >> is going to make the mistake of ever having multiple calling > >> conventions. Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> >> Unless Mac68K support is added.> >>> >> And here is some rationale even. The PC and Mac evolved from > >> "small" systems, where assembly programming was common, more > >> people knew more lower level details and playing games with > >> calling conventions was something anyone could do. Most other > >> current systems are rooted in C programming. Working in C, calling > >> conventions are generally in a hidden layer below what anyone > >> thinks about. Therefore, the smaller number of capable people > >> working at that level have the good sense to only have one calling > >> convention. No more systems will evolve from "small", at least not > >> without having observed this history. Therefore, there will no > >> longer be multiple calling conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >> only x86> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 13:05:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 13:05:56 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Hi again, the builds I started again this morning before leaving home seem to have succeeded again. I don't understand why compilation with the latest sources on my own system was broken though; I'll have to check that tonight. There's seems to be no immediate need for action though :-) It would be great if all committers would check the tinderbox status on http://www.opencm3.net at least after check-ins. You'll find it under "Status -> Tinderbox Tests", or directly at http://tinderbox.elegosoft.com/tinderbox/cm3/status.html. It contains links to all the build logs and the m3tests and package build test results, as well as a list of check-ins that may be responsible for any breakage (click on the dates in the left column). Olaf Quoting Olaf Wagner : > Tonight some of the tinderbox builds failed for CM3. First I thought > it was just these changes to FilePosix which had already been fixed: > > ---------------------------- > revision 1.8 > date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: > +1 -1; commitid: pvCLLyqdDKQm24Rs; > This checkin fixes something Jay left behind. > > Please check things build on platforms other than yours before making > changes. The VAL is necessary on some targets because 0 is INTEGER whereas > result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly > compared with an INTEGER (result). The VAL is how we do the conversion to > LONGINT. > > On platforms where Utypes.off_t is INTEGER this code will work the same as it > is. > ---------------------------- > revision 1.7 > date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs; > more cygwin header cleanup, various dead types were used > in further dead types in Ushm.i3; go ahead and delete > dead stuff instead of commenting out > remove seemingly unnecessary VAL() that fails to compile > > but when I try to build now on my FreeBSD system, I get this from cm3: > > % ./m3-sys/cm3/FreeBSD4/cm3 -version > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 > *** > > ^C > > Please check all the latest commits carefully and back out anything > that seems suspicious or has not been tested. > > Thanks, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Tue Feb 12 13:56:02 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 04:56:02 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." Message-ID: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Can you just generate the Modula-3 code you want using a Python script or COBOL or whatever you like instead of trying to foist preprocessing nastiness on innocent users of high-level Modula-3? Preprocessing is super nasty. It's not just a question of human readability. m3tk has to be able to read the code, too. I should be able to write a program that reads in (using m3tk) an arbitrary Modula-3 interface and understands it to the point that it can generate Network Object stubs, inter-language call stubs, etc. The stubs should ALSO be human- and m3tk-readable after the transformation! This should work even if the programmer has been very "clever" in his use of Modula-3 constructs. (Just try getting something like that to work with C or C++... it's hopeless once the preprocessor gets involved, and possibly before.) Also if I may make a little request, if at all possible, please try not to break binary compatibility with gcc-compiled C and Fortran on NT386GNU (not sure if your ideas about calling conventions could possibly do that...) Mika Jay writes: >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I insist that it depends. >Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code. >Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility. >A lot of #if here there and everywhere of course can have the opposite effe= >ct. >And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision. >It goes both ways. >=20 >Yes, you could endeavor factor things down so that everything common is in = >common, and everything not-common is in platform-specific. But this is inad= >equate I think. The tail is wagging the dog unnecessarily I think. If my co= >de very nearly all goes together, don't make me separate it. Also sometimes= > a different factoring is "encouraged" for other reasons, to match someone = >else's factoring. Look at the C*.i3 files. They actually can be almost all = >be nearly the same, yet they are hardly shared at all. I realize you could = >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >l the right capabilities for this. Type forwarding, sure. But how about pro= >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is lame anyway, you = >KIND OF want "module inheritance". However, if you allow preprocessing base= >d on target, perhaps the need for that goes away. >=20 >While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno. >=20 >A good /heuristic/ might be to change the default in any directory that has= > no c_source. >But it is only heuristic. >=20 >Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file. >Switching the default to the overwhelming majority and then annotating the = >minority is reasonable. >=20 >I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like: ><*EXTERN FOOAPI WINAPI*> fopen(); >FOOAPI for OS/FOO, WINAPI ignored. >WINAPI for NT386, FOOAPI ignored. >The One True Calling Convention for all others, calling convention ignored. >=20 >I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future. >The functions that are usually in need of calling conventions are usually o= >nly present on one system. >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant. >That could be also. >A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) ) >=20 >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e= >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20= >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:= >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform= > specific code > > should be in a separate file. I'd also like to see an op= >tion to > > move calling conventions to the makefile rather than in pramas = >to > > avoid having to duplicate interface files just to have a different >= > > calling convention for a different platform.> >> > - Darko> >> >> > On 1= >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug= >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good= > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit= >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi= >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >= >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm= >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >= > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr= >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >= >> etc.> >>> >> I don't really have enough interest here to work through thi= >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b= >y my happening into the odbc > >> directory and bringing up ignoring WINAPI= > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >This reminds me of an important point here however -- nobody else > >> is g= >oing to make the mistake of ever having multiple calling > >> conventions. = >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> = >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.= > The PC and Mac evolved from > >> "small" systems, where assembly programmi= >ng was common, more > >> people knew more lower level details and playing g= >ames with > >> calling conventions was something anyone could do. Most othe= >r > >> current systems are rooted in C programming. Working in C, calling >= > >> conventions are generally in a hidden layer below what anyone > >> thin= >ks about. Therefore, the smaller number of capable people > >> working at t= >hat level have the good sense to only have one calling > >> convention. No = >more systems will evolve from "small", at least not > >> without having obs= >erved this history. Therefore, there will no > >> longer be multiple callin= >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does= > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I insist that it depends.
>Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code.
>Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility.
>A lot of #if here there and everywhere of course can have the opposite effe= >ct.
>And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision.
>It goes both ways.
> 
>Yes, you could endeavor factor things down so that everything common i= >s in common, and everything not-common is in platform-specific. But this is= > inadequate I think. The tail is wagging the dog unnecessarily I think. If = >my code very nearly all goes together, don't make me separate it. = >;Also sometimes a different factoring is "encouraged" for other reasons, to= > match someone else's factoring. Look at the C*.i3 files. They actually can= > be almost all be nearly the same, yet they are hardly shared at all. I rea= >lize you could also do a sort of "forwarding", though I'm not sure that Mod= >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu= >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco= >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la= >me anyway, you KIND OF want "module inheritance". However, if you allow pre= >processing based on target, perhaps the need for that goes away.
> 
>While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno.
> 
>A good /heuristic/ might be to change the default in any directory that has= > no c_source.
>But it is only heuristic.
> 
>Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file.
>Switching the default to the overwhelming majority and then annotating the = >minority is reasonable.
> 
>I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like:
><*EXTERN FOOAPI WINAPI*> fopen();
>FOOAPI for OS/FOO, WINAPI ignored.
>WINAPI for NT386, FOOAPI ignored.
>The One True Calling Convention for all others, calling convention ignored.= >
> 
>I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o= >nly present on one system.
>Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant.
>That could be also.
>A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) )
> 
> 
> - Jay

> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c= >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&= >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g= >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro= >te:
>
> > I think it's not a good idea. I think all platfor= >m specific code
> > should be in a separate file. I'd also like t= >o see an option to
> > move calling conventions to the makefile r= >ather than in pramas to
> > avoid having to duplicate interface f= >iles just to have a different
> > calling convention for a differ= >ent platform.
> >
> > - Darko
> >
> >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >;> So I have NOT thought this through.
> >>
> >>= > I wonder if "preprocessing" dependent only on "target" is a good
> = >>> idea.
> >>
> >> Something like either the = >ability to prefix pragmas with a target,
> >> or an "iftarget"= > and "ifnottarget" pragma.
> >>
> >> Something like= > so:
> >>
> >> <* IF_TARGET NT386 *>
> = >>> <* END_IF_TARGET*>
> >>
> >>
>= > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*= >>
> >> It's a small can of worms.
> >> Where can= > they be placed? Only at "global" scope? (ie: toplevel in
> >>= > an interface/module).
> >>
> >> What about IF_OSTY= >PE?
> >> What about expressions?
> >> IF_TARGET NT3= >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>= >; >>
> >> etc.
> >>
> >> I don't = >really have enough interest here to work through this,
> >> ju= >st sending out the bait...
> >>
> >> Obviously this= > was triggered by my happening into the odbc
> >> directory an= >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c= >alling conventions with a target.
> >>
> >> This re= >minds me of an important point here however -- nobody else
> >>= >; is going to make the mistake of ever having multiple calling
> >= >;> conventions. Therefore the generality of prefixing WINAPI with
&g= >t; >> NT386: is useless.
> >> Unless Mac68K support is ad= >ded.
> >>
> >> And here is some rationale even. The= > PC and Mac evolved from
> >> "small" systems, where assembly = >programming was common, more
> >> people knew more lower level= > details and playing games with
> >> calling conventions was s= >omething anyone could do. Most other
> >> current systems are = >rooted in C programming. Working in C, calling
> >> convention= >s are generally in a hidden layer below what anyone
> >> think= >s about. Therefore, the smaller number of capable people
> >> = >working at that level have the good sense to only have one calling
>= > >> convention. No more systems will evolve from "small", at least no= >t
> >> without having observed this history. Therefore, there = >will no
> >> longer be multiple calling conventions.
> &= >gt;>
> >> That is my theory at least.
> >>
&g= >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall= > is
> >> only x86
>


Climb to the top= > of the charts!=A0Play the word scramble challenge with star power. =3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin= >k_jan' target=3D'_new'>Play now! >= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- From jayk123 at hotmail.com Tue Feb 12 14:18:18 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:18:18 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika, I'm not going to change the default calling convention. Don't worry. At "best", try it out, measure it, and then provide pragmas/command line switches if folks want largescale change, but never by default, and even command line switch could be dangerous..the safe form is it'd only affect implemented implementation in a directory with a particular m3makefile directive, it would not affect imported implementations. And this is way way way down any nonexistant list.. Probably more interesting than more efficient but "canonical" calling conventions is "whole program optimization" like cross "module (source file) inlining, custom calling conventions, cross function constant propagation, etc. Stuff all left to gcc. :) Moving to AMD64 will make this go away quite nicely. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:23:26 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:23:26 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <47B11DC9.1040902@wichita.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> <47B11DC9.1040902@wichita.edu> Message-ID: <20080212132326.GA22149@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > I don't think this is what Tony meant. In C++, an opening brace > starts a block, but every local declaration in that block has its own > unique scope that only starts at that declaration and goes to the end > of the block. This is particularly messy because the local declarations > of a block need not all precede all the statements, That is, in my opinion, one of the few things that C and C++ did right, well, almost right. It permits a coding style in which every variable declaration is initialised, and is declared if and only if it has a value. Now that's a useful property. It fails for recursion, so there are limits in how far it can apply. And when coding like this, you want the simplest syntax to define a constant identifier -- one whose value cannot be rebound except by reexecuting the entire block. Making something that can change should require more effort -- like adding a keyword "var" or some such. It's amazing how many identifiers end up fitting this constraint, yielding very little visual ambiguity as to whether the value of a variable has changed since initialisation. This tends to be the style in functional languages. In my opinion, functional-style languages would benefit from detailed static typing (as detailed as Modula 3) and some imperative features, like assignment to things that are explicitly declared as being variable. While rarely needed (but usually at least a few times per program), doing completely without imperative features I consider an exercise in masochism. But I can't see any way that this would fit seamlessly into Modula 3 syntax. -- hendrik > and even worse > because the distinction between declarations and statements is extremely > subtle and, unless things have changed, never actually defined. > > (Do you remember Stroustrup's famous quote when taken to task about this? > "If it looks like a declaration, it's a declaration. If it looks like a > statement, it's a statement. If it doesn't look like either, it's a > syntax error.") Last time I looked at it (when I was involved in a C++ implementation a decade or more ago) the rule was "If it looks like a declaration, it's a declaration; *otherwise* if it looks like a statement, it's a statement.", with precise constraints on what contextual information the compiler was allowed to look at when deciding what it looked like. The only correct way I found to implement this was to parse every statement-declaration-like thing first as a declaration, and, if that failed, as a statement. It was a mess. -- hendrik > In contrast, in Modula-3, the scope of every local declaration > starts at the beginning of the block and ends at the end of the > block. A simple rule, but, in my opinion, a little too simple. > > The C++ reference makes an attempt at defining different terms for the > entire block and the region where the identifier can be referred-to, i.e., > from declaration to end of block (which I have called "scope" here). > But as I recall, they ended up carefully defining their terminology in > one section but then not using it consistently in the rest of the > language definition. Their heart wasn't really into it, was it? Much rather let the implementation define the language. -- hendrik From mika at async.caltech.edu Tue Feb 12 14:41:31 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 05:41:31 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> Message-ID: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: >> I don't think this is what Tony meant. In C++, an opening brace >> starts a block, but every local declaration in that block has its own >> unique scope that only starts at that declaration and goes to the end >> of the block. This is particularly messy because the local declarations >> of a block need not all precede all the statements, > >That is, in my opinion, one of the few things that C and C++ did right, >well, almost right. It permits a coding style in which every >variable declaration is initialised, and is declared if and only if it You can do all kinds of fun stuff with C's declarations/initializations. switch (a) { int x=7; case 0: use(x); /* oops */ ... } goto somewherefun; { int y=7; somewherefun: use(y); /* oops again */ } >has a value. Now that's a useful property. It fails for recursion, >so there are limits in how far it can apply. And when coding like this, >you want the simplest syntax to define a constant identifier -- one >whose value cannot be rebound except by reexecuting the entire block. >Making something that can change should require more effort -- like >adding a keyword "var" or some such. Sounds to me like you're talking about Modula-3's WITH! Mika From jayk123 at hotmail.com Tue Feb 12 14:50:22 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:50:22 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika good point, I know that, forgot, thanks for reminding me. One of the interesting things about Modula-3, or rather anything but C and C++, is easy parsing, easy building of other tools. Just to be clear though, independent of my crazy ideas, such tools can't just enumerate a source tree. I guess they should operate over the pkg tree? You know, they can't understand the source tree without understanding m3makefiles. I started a little experiment here. I added m3-libs/m3core/src/C/common/Cstdio.i3. This is a file that ought to be nearly identical for all targets. For now I only changed NT386. I'm thinking either: a) I'm not quite on base and just fork it per-target, as it was b) provide a little bit of C code with #ifdefs, like making the SEEK_* constants into VARs and using C to initialize them. That's a bit of a downer though, since constants ought to be constants. c) factor it somehow as I was alluding, like, well, again I'm not sure Modula-3 has what I'd want here, but at least for types and constants, you can push the non-portable stuff into Ctargetstdio.i3 and then expose them in Cstdio.i3, forking only Ctargetstdio.i. I'll explain so I can get my question in. :) I understand, say: Ctargetstdio.i3 (* one of these per target, with not much content *) CONST SEEK_CUR = ..; (* target specific probably *) SEEK_SET = ..; ditto SEEK_END = ..; ditto TYPE FOO = ... ditto Cstdio.i3 (* portable *) CONST SEEK_CUR = Ctargetstdio.SEEK_CUR; SEEK_SET = Ctargetstdio.SEEK_SET; SEEK_END = Ctargetstdio.SEEK_END; TYPE FOO = Ctargetstdio.FOO; FILE = UNTRACED REF RECORD END; procedure fopen(a: const_char_star; b: const_char_star): FILE; It is tedious but I believe it works. It'd be nice, I think, if every symbol in one interface could be automatically aliases/exposed in another. At least for this purpose, maybe not for any other. I'm speculating here, so please respond kindly. :) The non portable types and constants can be pushed out and then reexposed as if they were portable and in one place. However, let's say, for argument/question's sake, that some function accepts int on some targets, off_t on another. Nevermind for now how you can portably call it. Ctargetstdio.i3 (* one of these for every target, but another question in a sec ... *) PROCEDURE seeksomething(a: off_t); let's say it is int on some platforms. Cstdio.i3 (* the portable one *) seeksomething = Ctargetstdio.seeksomething; does this work? I should try it out, read the docs. But then the next question would be, let's say there's 20 platforms and 5 use off_t and 15 use int. It's unfortunate if I have to repeat the content 20 times when there are only two variants. You can see this kind of thing where sometimes we include_dir(TARGET), sometimes include_dir(OS_TYPE). OS_TYPE implies less work, nice. Perhaps concatening stuff in arbitrary way with Quake really is the way? It seems almost sarcastic, but perhaps not. As long as the pkg store is easily parsed? (There's a setting to ship implementation files. I guess that must be left on? I thought it'd be nice to reduce distribution size..) But for that matter --- could be processed by the compiler and result in a file with it already accounted for and ship that. Isn't that just as good? EXCEPT that more thought would have to go into the spec, whereas m3makefile is already a general purpose system that anyone can do anything with? ?? - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:52:05 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:52:05 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <20080212135205.GC22149@topoi.pooq.com> On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > >> I don't think this is what Tony meant. In C++, an opening brace > >> starts a block, but every local declaration in that block has its own > >> unique scope that only starts at that declaration and goes to the end > >> of the block. This is particularly messy because the local declarations > >> of a block need not all precede all the statements, > > > >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations. > > switch (a) { > int x=7; > case 0: > use(x); /* oops */ > ... > } > > goto somewherefun; > > { > int y=7; > > somewherefun: > use(y); /* oops again */ > } That's more a problem with C's control structures. Each case should be a block of its own. The bits outside any case shouldn't be there. etc., etc. > > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such. > > Sounds to me like you're talking about Modula-3's WITH! Close, except for syntax. If you use WITH in the stype I'm advocating you end up with extremely deep syntactic nesting, and you indent off the side of the page. Also, the whole WITH syntax is quite heavy. -- hendrik From jayk123 at hotmail.com Tue Feb 12 15:02:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:02:23 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: C++ fixes this sort of thing. goto around initialization is an error. C++ constructors and destructors are a really good thing -- can't forgot to initialize or cleanup stuff. Very much like try/finally, but the finally code is better "positioned". Rather than special case memory with some fancy garbage collector, provide a mechanism for any type. RAII and all that. It's a very good theory at least. However I've become uncertain of it. Could be that a huge part of it is ok, if only you could train everyone in RAII and constructors/destructors. But then there are close pesky fopen/fclose/malloc/free you have to get rid of. And a lot of complexity around templates, unrelated, but can you allow C++ in a codebase but rigorously ban certain aspects? Maybe draw an analogy to Itanium. Lots of obviously good features, not even all that novel. But must we really combine them all together all at once? (register windows a la SPARC, loop unrolling a la any decent compiler..) And maybe memory is really vastly more interesting than other resources?Oh, and locks, special case those too... Mika your switch example, besides being invalid C++, is just not fair. I don't think people even think to write their code like that. Introducing variables at the top of a switch is rare, esp. initializing them. That C allows variables declared anywhere, and open braces anywhere, seems little known and little taken advantage of. Everyone just moves all the locals to the top, and either programmers do careful static flow analysis, or "lazily" (but reasonably) "over initialize" things, like maybe to 0 or { 0 }. C++ is what really fixes this properly and people know and understand it. Declare stuff anywhere, closest to first, use, and preferably initialized or a user defined type with a constructor. EXCEPT that it doesn't play nicely with goto, and if you aren't using exceptions, then goto is the next best thing...so then you are forced into something closer to the C style, though you gain constructors to help some. And hopefully the compiler can optimize away a lot of the unnecessary initialization... Java and I presume C# have a nice feature here too where they require the compiler to error for use of uninitialized variables, though I suspect the specced algorithm misses some things, like: if (...) initialize x common code if (same thing) use x <== possible use of uninitialize x, not At least I've seen other tools (not Java/C# compilers, I don't use those) get confused by this.. - Jay > To: hendrik at topoi.pooq.com> Date: Tue, 12 Feb 2008 05:41:31 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > hendrik at topoi.pooq.com writes:> >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> >> I don't think this is what Tony meant. In C++, an opening brace> >> starts a block, but every local declaration in that block has its own> >> unique scope that only starts at that declaration and goes to the end> >> of the block. This is particularly messy because the local declarations> >> of a block need not all precede all the statements,> >> >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations.> > switch (a) {> int x=7;> case 0:> use(x); /* oops */> ...> }> > goto somewherefun;> > {> int y=7;> > somewherefun:> use(y); /* oops again */> }> > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such.> > Sounds to me like you're talking about Modula-3's WITH!> > Mika _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 15:05:46 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:05:46 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080212135205.GC22149@topoi.pooq.com> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: Agreed! C++ vs. WITH, C++ wins by not indenting unnecessarily. See that change I was fiddling with in Time.m3 for examle. Hm. Can we get consensus on a language change? :) BEGIN VAR a := 1; IO.PutInt(a); VAR b := 2, (* ? *) c := 3; (* ? *) IO.PutInt(b); ? Easier to require "VAR" on each, a bit wordy. - Jay > Date: Tue, 12 Feb 2008 08:52:05 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote:> > hendrik at topoi.pooq.com writes:> > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> > >> I don't think this is what Tony meant. In C++, an opening brace> > >> starts a block, but every local declaration in that block has its own> > >> unique scope that only starts at that declaration and goes to the end> > >> of the block. This is particularly messy because the local declarations> > >> of a block need not all precede all the statements,> > >> > >That is, in my opinion, one of the few things that C and C++ did right, > > >well, almost right. It permits a coding style in which every > > >variable declaration is initialised, and is declared if and only if it > > > > You can do all kinds of fun stuff with C's declarations/initializations.> > > > switch (a) {> > int x=7;> > case 0:> > use(x); /* oops */> > ...> > }> > > > goto somewherefun;> > > > {> > int y=7;> > > > somewherefun:> > use(y); /* oops again */> > }> > That's more a problem with C's control structures. Each case should be > a block of its own. The bits outside any case shouldn't be there. > etc., etc.> > > > > > > >has a value. Now that's a useful property. It fails for recursion, > > >so there are limits in how far it can apply. And when coding like this, > > >you want the simplest syntax to define a constant identifier -- one > > >whose value cannot be rebound except by reexecuting the entire block. > > >Making something that can change should require more effort -- like > > >adding a keyword "var" or some such.> > > > Sounds to me like you're talking about Modula-3's WITH!> > Close, except for syntax. If you use WITH in the stype I'm > advocating you end up with extremely deep syntactic nesting, and you > indent off the side of the page. Also, the whole WITH syntax is quite > heavy.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 16:57:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 15:57:25 +0000 Subject: [M3devel] utime.i3 and imported data Message-ID: For good reason, imported (dynamically linked) data doesn't work great on Win32. Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];} for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 17:27:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 16:27:38 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: sorry, still not a bad idea, but not where my crash is. I wasn't paying close enough attention. Those aren't used on NT386GNU. The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone); I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:07:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:07:24 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: well..we were accessing fields at the end of struct tm that aren't there..switched from DateBsd to DateLinux and now my exact first proposal stands. :) I worked around but it is lame, imho more lame than my suggestion. My suggestion still imports/shares the data, just via a C function call, so that the right declarations are present. The right declarations are..difficult in Modula-3. You'd have to declare the variables as pointers and change their name, and then somehow either layer portable code over that, or fork DateBsd/DateLinux to DateCygwin..which I just don't think is worth it. I don't like per-platform forks, too much duplicity, too much multiplication out of code, too much code, too much cruft, too little maintenance.... better to merge stuff if it isn't a mess and have less overall source code to maintain.... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] utime.i3 and imported dataDate: Tue, 12 Feb 2008 16:27:38 +0000 sorry, still not a bad idea, but not where my crash is.I wasn't paying close enough attention. Those aren't used on NT386GNU.The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone);I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:21:15 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:21:15 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: I think I just said this over the weekend, but really, I should be able to put in modules and not be forced to put them in an interface. Look at the cygwin Utime.i3/m3/C.c for example... Yeah, it's a workaround, that I'd like to remove, but it could easily represent a non-workaround.. There's no real "interface/module" here, it's just that I wrote some of the code in C. sorry to be such an annoying whiner..but I ran into this multiple times over a short span of time... - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:26:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:26:24 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: Jay, Modula-3 has a perfectly good way of saying what you want as PACKED types. Whether they are fully implemented or not is another question. -- Tony On Feb 12, 2008, at 6:34 AM, Jay wrote: > I strongly suggest that at least in some contexts, no padding ever > be quietly inserted, and that all seeming need for padding generate > an error, unless explicitly quashed, preferably by explicit > insertion of padding fields by the programmer, and/or rearrangement > sorted by size, or possibly some annotation of the overall struct/ > record/class/module, an annotation such as <* silent padding ok*>. > Alignment issues really bug me... > I realize many data structures are only ever seen in memory, by one > process, so it doesn't matter, but when it matter, the languages/ > tools seem to fall down. > As well, "padding" fields should be annotated as such and the > compiler warn or error if they aren't needed. > > It's just dumb that code like: > > struct > { > int32 a; > int64 b; > }; > > when defining some stable important binary layout can have a > varying but silently allowed meaning based on command line switches > or targets.. Yes, I'm a dumb programmer to write it, but man the > tools are lagging. > > This will fall on deaf ears and far from sufficient ears even if > they were hearing. > It's the C compilers that are somewhat broken here imho. > C is unnecessarily broken here. Imho it's a big cause for headaches > and easily solved....it doesn't have to stink so badly, if anyone > cared.. > > I have had to maintain structs that had to look the same across > different targets and therefore insert target-dependent padding. > Ok, but it should have been easier. When I was done, I put in > compile time asserts as to the offset of every single field so the > next guy would have an easier time, and assiduously commented every > byte of padding in the struct and its target-dependentness.... > This was like for shared memory. > > Grumble, > - Jay > > > > > From: darko at darko.org > > To: rodney.bates at wichita.edu > > Date: Tue, 12 Feb 2008 15:37:52 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] <*LAZYALIGN*> > > > > That's not quite right. Certain Mac API structures need to be > aligned > > to Motorola 68K alignment for historical reasons. All other > structures > > should use normal alignment to be compatible with C and Unix > > interfaces. The alignment change was implemented to be supported > only > > in packed structures as a natural and intuitive way to "force" > > alignment. You could view it as a bug fix to overly restrictive > > alignment rules in packed structures. > > > > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > > > > > It sounds like all that Mac OS X needs is for _all_ types in an > entire > > > program to use the liberal packing rules. Have I understood > > > correctly? > > > I would have no grief over that. > > > > > > Darko wrote: > > >> The liberalised alignment rules are required for the native > Mac OS > > >> X API and should stay. You cannot use that API without them. I > > >> think the pragma is not required and can be removed. I agree with > > >> all the points you make. The effect of the modified alignment > > >> rules it to allow *packed* structures to have members aligned on > > >> byte boundaries. This has the effect of packing the fields in the > > >> tightest arrangement allowed by the platform. This might affect > > >> performance, but if the user is concerned about this they should > > >> specify field bit sizes that deliver improved performance. I > don't > > >> see a need to specify this on a structure level, for the reasons > > >> you give and because the difference isn't significant enough in > > >> the case of packed structures and their physical layout and > > >> restrictions are platform dependent anyway. > > >> I might also add that the alignment code is currently broken on > > >> I386_DARWIN. > > >> - Darko > > >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > > >>> Does anybody know about the status of pragma <*LAZYALIGN*>? > Is it > > >>> being used anywhere? > > >>> > > >>> It is not documented in pragmas.html. The compiler front end > > >>> appears > > >>> to accept it. (In fact, Decls.m3 contains constants that suggest > > >>> limitations on what declarations the pragma can appear on, > but these > > >>> are not actually enforced.) It liberalizes the alignment rules, > > >>> generally allowing scalars to start on any byte boundary. > > >>> > > >>> Pickles have to be able to reconstruct the layout of types as > the > > >>> compiler would have done it for a machine (on which a now- > being-read > > >>> pickle was written) with different word size and alignment > > >>> properties. > > >>> Currently, pickles are completely unaware of lazy alignment. It > > >>> would have to be encoded in type descriptions generated by the > > >>> compiler > > >>> using TipeDesc and read by pickles using RTTipe. > > >>> > > >>> Most troubling to me is what looks like a linguistic > Pandora's box. > > >>> The pragma can be associated with any constant, variable, or > type > > >>> _declaration_ (not type definition), with the result that > different > > >>> values of the same type can actually be different in their > alignment > > >>> rules and thus their layout. Similarly for different identifiers > > >>> equated to the same type. Although the effects of this could > > >>> possibly > > >>> be hidden from the programmer in purely safe code, not so with > > >>> unsafe > > >>> code. I haven't thoroughly thought this through, but seems to me > > >>> to > > >>> really fly in the face of the whole typing philosophy of the > > >>> language. > > >>> > > >>> For example, if pickles were to read in an object value, and > there > > >>> were >1 variants of the object's type in the reading program, > > >>> differing > > >>> only in the alignment rules, how would it decide which one to > build? > > >>> In fact, ignoring pickles altogether and just looking at a > single > > >>> program, > > >>> if the object's type doesn't actually uniquely give its memory > > >>> layout, > > >>> how can it be accessed correctly? > > >>> > > >>> Additionally, a quick look at the compiler suggests it won't > > >>> generate > > >>> correct code for whole record assignment when the LHS and RHS > are > > >>> the > > >>> same type but have different alignment characteristics. > > >>> > > >>> The more I think about it, it seems the only workable > > >>> possibilities are: > > >>> > > >>> 1) Require the pragma to be associated only with a type > > >>> _definition_ not a > > >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > > >>> this a > > >>> property of the type that propagates to all names for the > type and > > >>> all variables, constants, etc. Also, this would make this > property > > >>> a part of the type signature that pickles uses when reading, - > OR- > > >>> > > >>> 2) Forget it altogether. > > >>> > > >>> What do people think? > > >>> -- > > >>> ------------------------------------------------------------- > > >>> 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 > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Tue Feb 12 18:33:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:33:01 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: This was to "fix" building NT386GNU because lseek was returning int or long instead of off_t. My mistake by changing the wrong side of things. The return type is fixed and NT386GNU is ok with the "VAL". - Jay From: jayk123 at hotmail.comTo: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.comSubject: val?Date: Tue, 12 Feb 2008 06:22:28 +0000 Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available.There is/was a compilation problem with what I was doing.I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:34:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:34:12 -0500 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: <8B40FF77-0AF5-4907-9935-03CEE1E24BB7@cs.purdue.edu> Thanks Jay and Olaf for your explanations. I am only ever a general user of the scripts, but perhaps as a maintainer I should understand them better. On Feb 12, 2008, at 5:34 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I notice scripts/PKGS is no longer in the repository. Does this get >> generated somehow now? I know that do-cm3-std.sh depends on it >> because >> my copy of PKGS was broken (missing sysutils). Can someone >> explain to >> me how the build scripts have changed and how I should be using them? > > PKGS has never been checked-in and should not as far as I know. > It contains workspace-dependent paths and is built by find-packages.sh > if I remember correctly. All shell scripts will generate it if it > does not exist. It can be deleted any time, and indeed must be deleted > if packages are added (or they will not be found). This is arguably > a bug, > but then all the scripts were never intended to be a general user > interface > for CM3 users (only for the maintenance). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 12 18:42:01 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:01 -0500 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Aren't these all superseded by gettimeofday? I say just not support the global variable access. Utime.i3 on other platforms does not have these globals. On Feb 12, 2008, at 12:07 PM, Jay wrote: > well..we were accessing fields at the end of struct tm that aren't > there..switched from DateBsd to DateLinux and now my exact first > proposal stands. :) > > I worked around but it is lame, imho more lame than my suggestion. > My suggestion still imports/shares the data, just via a C function > call, so that the right declarations are present. > The right declarations are..difficult in Modula-3. > You'd have to declare the variables as pointers and change their > name, and then somehow either layer portable code over that, or > fork DateBsd/DateLinux to DateCygwin..which I just don't think is > worth it. I don't like per-platform forks, too much duplicity, too > much multiplication out of code, too much code, too much cruft, too > little maintenance.... better to merge stuff if it isn't a mess and > have less overall source code to maintain.... > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] utime.i3 and imported data > Date: Tue, 12 Feb 2008 16:27:38 +0000 > > sorry, still not a bad idea, but not where my crash is. > I wasn't paying close enough attention. Those aren't used on NT386GNU. > The crash is probably here: > > C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): > date.zone := M3toC.CopyStoT (tm.tm_zone); > > I don't know why yet. (meta reason -- these time formats aren't > worthwhile even if forward slashes in paths and X Windows are....) > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Tue, 12 Feb 2008 15:57:25 +0000 > Subject: [M3devel] utime.i3 and imported data > > For good reason, imported (dynamically linked) data doesn't work > great on Win32. > Functions work much better. Data can work, but you generally need > the header to say __declspec(dllimport), to change it to a > declaration of a pointer. I've seen GNU ld has some workaround but > I'm not familiar with it, it doesn't worthwhile to me, and I'm > having a problem. > > I strongly suggest all the Utime.i3: > > <*EXTERNAL*> VAR timezone: time_t; > <*EXTERNAL*> VAR daylight: int; > <*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; > > be changed to functions: > > <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t; > <*EXTERNAL Utime__get_daylight*> get_daylight(): int; > <*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; > > > with an implementation in C: > > UtimeC.c > #include > time_t Utime__get_timezone(void) > { > return timezone; > } > > int Utime__get_daylight(void) > { > return daylight; > } > > char* Utime__get_tzname(unsigned a) > { > return tzname[a]; > } > > for now I'm going to try another workaround..where NT386GNU has > this data as not external and some C code to call tzset and then > copy the data from the C globals to Modula-3 globals. > > The datetime feature I added to Quake is crashing, I think due to > this... > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:42:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:57 -0500 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: The globals are gross, and not available on other platforms. Let's just drop them... On Feb 12, 2008, at 12:21 PM, Jay wrote: > I think I just said this over the weekend, but really, I should be > able to put in modules and not be forced to put them in an > interface. > Look at the cygwin Utime.i3/m3/C.c for example... > Yeah, it's a workaround, that I'd like to remove, but it could > easily represent a non-workaround.. > There's no real "interface/module" here, it's just that I wrote > some of the code in C. > > sorry to be such an annoying whiner..but I ran into this multiple > times over a short span of time... > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:43:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:43:53 -0500 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: The log tells the story much better than random comments in the code. On Feb 12, 2008, at 1:18 AM, Jay wrote: > I added some files a while ago and someone either complained or > added them, so I've been adding them since. > > - Jay > > > > Date: Tue, 12 Feb 2008 05:20:47 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 08/02/12 05:20:47 > > > > Modified files: > > cm3/m3-sys/cm3/src/: m3makefile > > > > Log message: > > Let's avoid RCS id stuff shall we. Just clutters up the files... > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Tue Feb 12 18:50:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:50:03 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: <98447784-CE9A-40E4-8305-DA711A0EEBE1@cs.purdue.edu> Hear hear! On Feb 12, 2008, at 7:56 AM, Mika Nystrom wrote: > > Can you just generate the Modula-3 code you want using a Python > script or COBOL or whatever you like instead of trying to foist > preprocessing nastiness on innocent users of high-level Modula-3? > > Preprocessing is super nasty. It's not just a question of human > readability. m3tk has to be able to read the code, too. I should > be able to write a program that reads in (using m3tk) an arbitrary > Modula-3 interface and understands it to the point that it can > generate Network Object stubs, inter-language call stubs, etc. The > stubs should ALSO be human- and m3tk-readable after the > transformation! > This should work even if the programmer has been very "clever" in > his use of Modula-3 constructs. (Just try getting something like > that to work with C or C++... it's hopeless once the preprocessor > gets involved, and possibly before.) > > Also if I may make a little request, if at all possible, please try > not to break binary compatibility with gcc-compiled C and Fortran > on NT386GNU (not sure if your ideas about calling conventions could > possibly do that...) > > Mika > > Jay writes: >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> I insist that it depends. >> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code. >> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility. >> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct. >> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision. >> It goes both ways. >> =20 >> Yes, you could endeavor factor things down so that everything >> common is in = >> common, and everything not-common is in platform-specific. But >> this is inad= >> equate I think. The tail is wagging the dog unnecessarily I think. >> If my co= >> de very nearly all goes together, don't make me separate it. Also >> sometimes= >> a different factoring is "encouraged" for other reasons, to match >> someone = >> else's factoring. Look at the C*.i3 files. They actually can be >> almost all = >> be nearly the same, yet they are hardly shared at all. I realize >> you could = >> also do a sort of "forwarding", though I'm not sure that Modula-3 >> offers al= >> l the right capabilities for this. Type forwarding, sure. But how >> about pro= >> cedure forwarding? Like nt386\cstdio.i3 fopen =3D common >> \ccommonstdio.i3 fo= >> pen? And having to duplicate a line per type/procedure is lame >> anyway, you = >> KIND OF want "module inheritance". However, if you allow >> preprocessing base= >> d on target, perhaps the need for that goes away. >> =20 >> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno. >> =20 >> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source. >> But it is only heuristic. >> =20 >> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file. >> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable. >> =20 >> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like: >> <*EXTERN FOOAPI WINAPI*> fopen(); >> FOOAPI for OS/FOO, WINAPI ignored. >> WINAPI for NT386, FOOAPI ignored. >> The One True Calling Convention for all others, calling convention >> ignored. >> =20 >> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future. >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system. >> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant. >> That could be also. >> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) ) >> =20 >> =20 >> - Jay >> >> >> >>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: >>> hosking at cs.purdue.e= >> du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, >> 11 Feb 20= >> 08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, >> 2008, at 8:= >> 37 PM, Darko wrote:> > > I think it's not a good idea. I think all >> platform= >> specific code > > should be in a separate file. I'd also like to >> see an op= >> tion to > > move calling conventions to the makefile rather than >> in pramas = >> to > > avoid having to duplicate interface files just to have a >> different >= >>> calling convention for a different platform.> >> > - Darko> >> >> >>> > On 1= >> 2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought >> this throug= >> h.> >>> >> I wonder if "preprocessing" dependent only on "target" >> is a good= >>>>> idea.> >>> >> Something like either the ability to prefix >>>>> pragmas wit= >> h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> >> Somethi= >> ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> >>> >>> >= >>> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can >>> of worm= >> s.> >> Where can they be placed? Only at "global" scope? (ie: >> toplevel in >= >>>> an interface/module).> >>> >> What about IF_OSTYPE?> >> What >>>> about expr= >> essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS >> (NT)> >>> >= >>> etc.> >>> >> I don't really have enough interest here to work >>> through thi= >> s, > >> just sending out the bait...> >>> >> Obviously this was >> triggered b= >> y my happening into the odbc > >> directory and bringing up >> ignoring WINAPI= >> on non-NT386 or > >> prefixing calling conventions with a target.> >> >>> >> = >> This reminds me of an important point here however -- nobody else >> > >> is g= >> oing to make the mistake of ever having multiple calling > >> >> conventions. = >> Therefore the generality of prefixing WINAPI with > >> NT386: is >> useless.> = >>>> Unless Mac68K support is added.> >>> >> And here is some >>>> rationale even.= >> The PC and Mac evolved from > >> "small" systems, where assembly >> programmi= >> ng was common, more > >> people knew more lower level details and >> playing g= >> ames with > >> calling conventions was something anyone could do. >> Most othe= >> r > >> current systems are rooted in C programming. Working in C, >> calling >= >>>> conventions are generally in a hidden layer below what anyone > >>>> >> thin= >> ks about. Therefore, the smaller number of capable people > >> >> working at t= >> hat level have the good sense to only have one calling > >> >> convention. No = >> more systems will evolve from "small", at least not > >> without >> having obs= >> erved this history. Therefore, there will no > >> longer be >> multiple callin= >> g conventions.> >>> >> That is my theory at least.> >>> >> Oh, >> Windows does= >> also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >> _________________________________________________________________ >> Climb to the top of the charts!=A0Play the word scramble challenge >> with sta= >> r power. >> http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlink_ja= >> n= >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> I insist that it depends.
>> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code.
>> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility.
>> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct.
>> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision.
>> It goes both ways.
>>  
>> Yes, you could endeavor factor things down so that everything >> common i= >> s in common, and everything not-common is in platform-specific. >> But this is= >> inadequate I think. The tail is wagging the dog unnecessarily I >> think. If = >> my code very nearly all goes together, don't make me separate >> it. = >> ;Also sometimes a different factoring is "encouraged" for other >> reasons, to= >> match someone else's factoring. Look at the C*.i3 files. They >> actually can= >> be almost all be nearly the same, yet they are hardly shared at >> all. I rea= >> lize you could also do a sort of "forwarding", though I'm not sure >> that Mod= >> ula-3 offers all the right capabilities for this. Type forwarding, >> sure. Bu= >> t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D >> common\cco= >> mmonstdio.i3 fopen? And having to duplicate a line per type/ >> procedure is la= >> me anyway, you KIND OF want "module inheritance". However, if you >> allow pre= >> processing based on target, perhaps the need for that goes away.
>>  
>> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno.
>>  
>> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source.
>> But it is only heuristic.
>>  
>> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file.
>> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable.
>>  
>> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like:
>> <*EXTERN FOOAPI WINAPI*> fopen();
>> FOOAPI for OS/FOO, WINAPI ignored.
>> WINAPI for NT386, FOOAPI ignored.
>> The One True Calling Convention for all others, calling convention >> ignored.= >>
>>  
>> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future.>> >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system.
>> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant.
>> That could be also.
>> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) )
>>  
>>  
>>  - Jay

>> >>
>>
>> > CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: >> hosking at c= >> s.purdue.edu
> Subject: Re: [M3devel] "target specific >> pragmas"?
&= >> gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: >> darko at darko.org
&g= >> t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, >> Darko wro= >> te:
>
> > I think it's not a good idea. I think >> all platfor= >> m specific code
> > should be in a separate file. I'd >> also like t= >> o see an option to
> > move calling conventions to the >> makefile r= >> ather than in pramas to
> > avoid having to duplicate >> interface f= >> iles just to have a different
> > calling convention for >> a differ= >> ent platform.
> >
> > - Darko
> >> >
> >> R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >> >
> >= >> ;> So I have NOT thought this through.
> >>
> >> >>= >> I wonder if "preprocessing" dependent only on "target" is a good >>
> = >> >> idea.
> >>
> >> Something like >> either the = >> ability to prefix pragmas with a target,
> >> or an >> "iftarget"= >> and "ifnottarget" pragma.
> >>
> >> >> Something like= >> so:
> >>
> >> <* IF_TARGET NT386 >> *>
> = >> >> <* END_IF_TARGET*>
> >>
> >> >>
>= >> >> <* IF_TARGET NT386 *>
> >> <* >> END_IF_TARGET*= >> >
> >> It's a small can of worms.
> >> >> Where can= >> they be placed? Only at "global" scope? (ie: toplevel in
> >> >>= >> an interface/module).
> >>
> >> What about >> IF_OSTY= >> PE?
> >> What about expressions?
> >> >> IF_TARGET NT3= >> 86 OR NTAMD64
> >>
> >> IF_TARGET STARTS >> (NT)
>= >> ; >>
> >> etc.
> >>
> >> >> I don't = >> really have enough interest here to work through this,
> >> >> ju= >> st sending out the bait...
> >>
> >> >> Obviously this= >> was triggered by my happening into the odbc
> >> >> directory an= >> d bringing up ignoring WINAPI on non-NT386 or
> >> >> prefixing c= >> alling conventions with a target.
> >>
> >> >> This re= >> minds me of an important point here however -- nobody else >>
> >>= >> ; is going to make the mistake of ever having multiple calling >>
> >= >> ;> conventions. Therefore the generality of prefixing WINAPI >> with
&g= >> t; >> NT386: is useless.
> >> Unless Mac68K >> support is ad= >> ded.
> >>
> >> And here is some rationale >> even. The= >> PC and Mac evolved from
> >> "small" systems, where >> assembly = >> programming was common, more
> >> people knew more >> lower level= >> details and playing games with
> >> calling >> conventions was s= >> omething anyone could do. Most other
> >> current >> systems are = >> rooted in C programming. Working in C, calling
> >> >> convention= >> s are generally in a hidden layer below what anyone
> >> >> think= >> s about. Therefore, the smaller number of capable people
> >> >> = >> working at that level have the good sense to only have one calling >>
>= >> >> convention. No more systems will evolve from "small", at >> least no= >> t
> >> without having observed this history. >> Therefore, there = >> will no
> >> longer be multiple calling >> conventions.
> &= >> gt;>
> >> That is my theory at least.
> >> >>
&g= >> t; >> Oh, Windows does also have __thiscall and __clrcall. >> __thiscall= >> is
> >> only x86
>


Climb to >> the top= >> of the charts!=A0Play the word scramble challenge with star power. >> > =3D'http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlin= >> k_jan' target=3D'_new'>Play now! >> = >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_-- From hosking at cs.purdue.edu Tue Feb 12 18:54:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:54:15 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212130518.F0C7B10D4659@birch.elegosoft.com> References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: Jay, I *really* dislike the idea that you are putting target-specific code in a subdirectory labeled Common! If I want to search for target-specific stuff I grep for directories labeled by that target. Please, please, please think about the global picture before making these sorts of local changes! Please back this change out and put this where it belongs in cm3/m3- libs/m3core/src/C/NT386. I am happy to do it for you but I have other things to do with my time! On Feb 12, 2008, at 2:05 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 14:05:18 > > Modified files: > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c > > Log message: > fix (NT386 only) From hosking at cs.purdue.edu Tue Feb 12 19:00:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 13:00:39 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212125650.7DE8D10D4659@birch.elegosoft.com> References: <20080212125650.7DE8D10D4659@birch.elegosoft.com> Message-ID: <3BDD1B0E-CD23-43D1-9BC0-7B36FE6024AF@cs.purdue.edu> The C stuff is not intended to expose a full C API to Modula-3 programmers. It is there mostly for bridging to C-based libraries, particularly platform-specific functionality for platforms that are implemented in C. Some of that bridging is done in the OS-specific unix subdirectories and some in the C subdirectories. Choosing where to put that bridge code is a matter of style I guess, but it should probably be a matter of consensus among the developers of CM3. So, do folks out there have any opinions on how to best structure these bridging portions of m3core? I would argue for the minimum needed to support core M3 functionality. Jay seems to want to throw everything including the kitchen sink into the core libraries. I would argue that doing so makes the job of maintaining and porting Modula-3 a little more onerous. On Feb 12, 2008, at 1:56 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 13:56:50 > > Added files: > cm3/m3-libs/m3core/src/unix/NT386/: Unix.i3 Uuio.i3 > > Log message: > a fair amount of "unix i/o" is directly provided by msvcr*.dll and > should perhaps be exposed /somewhere/. Here is a start, of sorts. From dragisha at m3w.org Tue Feb 12 18:58:44 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 18:58:44 +0100 Subject: [M3devel] wtf "code generation errors"? Message-ID: <1202839124.623.1.camel@faramir.m3w.org> % cm3 --- building in ../LINUXLIBC6 --- new source -> compiling Connection.i3 new source -> compiling Connection.m3 new source -> compiling PDU.i3 new source -> compiling PDU.m3 "../src/PDU.m3", line 107: warning: not used (len) "../src/PDU.m3", line 104: warning: not used (b) "../src/PDU.m3", line 116: warning: open array passed by value (o) "../src/PDU.m3", line 118: warning: not used (cStr) "../src/PDU.m3", line 116: warning: not used (b) "../src/PDU.m3", line 116: warning: not used (o) "../src/PDU.m3", line 160: warning: not used (c) "../src/PDU.m3", line 59: warning: not used (GetInt) 8 warnings encountered new source -> compiling SMPP.m3 "../src/SMPP.m3", line 1: 4 code generation errors 1 error encountered compilation failed => not building program "smpp" Fatal Error: package build failed -- Dragi?a Duri? From hendrik at topoi.pooq.com Tue Feb 12 20:13:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 14:13:38 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: <20080212191338.GA24578@topoi.pooq.com> On Tue, Feb 12, 2008 at 02:05:46PM +0000, Jay wrote: > Agreed! > C++ vs. WITH, C++ wins by not indenting unnecessarily. > See that change I was fiddling with in Time.m3 for examle. > > Hm. Can we get consensus on a language change? :) > > BEGIN VAR a := 1; > IO.PutInt(a); > VAR b := 2, (* ? *) > c := 3; (* ? *) > IO.PutInt(b); > > ? Easier to require "VAR" on each, a bit wordy. > > - Jay That would work. But I'd use CONST more than VAR (if I had a choice) And I'd like to be able to specify the type. I'm a fanatic about making types explicit. -- hendrik From hosking at cs.purdue.edu Tue Feb 12 21:05:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 15:05:43 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202839124.623.1.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: Did something change in m3middle/m3front lately? On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > % cm3 > --- building in ../LINUXLIBC6 --- > > new source -> compiling Connection.i3 > new source -> compiling Connection.m3 > new source -> compiling PDU.i3 > new source -> compiling PDU.m3 > "../src/PDU.m3", line 107: warning: not used (len) > "../src/PDU.m3", line 104: warning: not used (b) > "../src/PDU.m3", line 116: warning: open array passed by value (o) > "../src/PDU.m3", line 118: warning: not used (cStr) > "../src/PDU.m3", line 116: warning: not used (b) > "../src/PDU.m3", line 116: warning: not used (o) > "../src/PDU.m3", line 160: warning: not used (c) > "../src/PDU.m3", line 59: warning: not used (GetInt) > 8 warnings encountered > new source -> compiling SMPP.m3 > "../src/SMPP.m3", line 1: 4 code generation errors > 1 error encountered > compilation failed => not building program "smpp" > Fatal Error: package build failed > > -- > Dragi?a Duri? From rcoleburn at scires.com Tue Feb 12 21:16:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 12 Feb 2008 15:16:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <47B1B848.1E75.00D7.1@scires.com> Jay: My understanding of Modula-3 is that rather than cluttering up the source code with a bunch of preprocessor directives to deal with the various changes needed by various platforms, a separate source file is used for platforms whose implementation must diverge. The m3makefile is used to control the selection of these platform sources at build time. I like this approach much better. Regards, Randy >>> Jay 2/11/2008 8:21 PM >>> So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 12 22:12:45 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:12:45 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 13:50:22 GMT." Message-ID: <200802122112.m1CLCjU0006778@camembert.async.caltech.edu> Your seeksomething = Ctargetstdio.seeksomething should work. Another thing that might work well is to use generics. For instance, have some interfaces Win32Types.i3 MacOSTypes.i3 FreeBSDTypes.i3 And then build your other stuff as generics passing in OSTypes... of course you can't do *everything* with generics, but type variants you can do. About preprocessing. It's clear you're going to have variable code. When you deal with OS things, of course you will. Currently this variability is expressed in Quake. There's no way of getting away from a certain amount of variability as long as you're interfacing with an OS, I think we all know that. But there's a difference between doing it in Quake and in Modula-3, which is why I used the expression "foisting preprocessing on innocent users of high-level Modula-3". As long as you do it in Quake, no one will expect things like m3tk to work properly all the time. Once you do it in Modula-3 itself, however, you're inviting users to code absolutely normal modules with preprocessing that really have no need for preprocessing. You can't really say "here's a part of the language we're using that you probably shouldn't use." If it's there, you have to expect programmers to use it. If it's not, if they do weird things in Quake, or generate code in Python, on the other hand, they themselves had better know what they are doing. Mika Jay writes: >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Mika good point, I know that, forgot, thanks for reminding me. > One of the interesting things about Modula-3, or rather anything but C an= >d C++, is easy parsing, easy building of other tools. >=20 >Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the pkg tree? = >You know, they can't understand the source tree without understanding m3mak= >efiles. >=20 >I started a little experiment here. >I added m3-libs/m3core/src/C/common/Cstdio.i3. >This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386. >I'm thinking either: > a) I'm not quite on base and just fork it per-target, as it was > b) provide a little bit of C code with #ifdefs, like making the SEEK_* c= >onstants into VARs and using C to initialize them. That's a bit of a downer= > though, since constants ought to be constants. > c) factor it somehow as I was alluding, like, well, again I'm not sure M= >odula-3 has what I'd want here, but at least for types and constants, you c= >an push the non-portable stuff into Ctargetstdio.i3 and then expose them in= > Cstdio.i3, forking only Ctargetstdio.i. >=20 >I'll explain so I can get my question in. :) >=20 >I understand, say: >=20 >Ctargetstdio.i3 (* one of these per target, with not much content *)=20 >CONST > SEEK_CUR =3D ..; (* target specific probably *)=20 > SEEK_SET =3D ..; ditto=20 > SEEK_END =3D ..; ditto =20 >TYPE > FOO =3D ... ditto =20 >=20 >Cstdio.i3 (* portable *)=20 > CONST > SEEK_CUR =3D Ctargetstdio.SEEK_CUR; > SEEK_SET =3D Ctargetstdio.SEEK_SET; > SEEK_END =3D Ctargetstdio.SEEK_END; >TYPE > FOO =3D Ctargetstdio.FOO; >=20 >FILE =3D UNTRACED REF RECORD END; >=20 > procedure fopen(a: const_char_star; b: const_char_star): FILE; >=20 >It is tedious but I believe it works. >It'd be nice, I think, if every symbol in one interface could be automatica= >lly aliases/exposed in another. > At least for this purpose, maybe not for any other. I'm speculating here,= > so please respond kindly. :) >The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place. >=20 >However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another. >Nevermind for now how you can portably call it. >=20 >Ctargetstdio.i3 (* one of these for every target, but another question in a= > sec ... *) >=20 > PROCEDURE seeksomething(a: off_t); let's say it is int on some pl= >atforms. >=20 >Cstdio.i3 (* the portable one *) >=20 >seeksomething =3D Ctargetstdio.seeksomething; does this work? I should t= >ry it out, read the docs. >=20 >But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int. >It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants. >You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE). >OS_TYPE implies less work, nice. >=20 >Perhaps concatening stuff in arbitrary way with Quake really is the way? >It seems almost sarcastic, but perhaps not. >=20 >As long as the pkg store is easily parsed? >(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..) >=20 >But for that matter --- could be processed by the compiler and = >result in a file with it already accounted for and ship that. Isn't that ju= >st as good? EXCEPT that more thought would have to go into the spec, wherea= >s m3makefile is already a general purpose system that anyone can do anythin= >g with? >=20 >?? >=20 > - Jay > > > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From:= > mika at async.caltech.edu> > > Can you just generate the Modula-3 code you wa= >nt using a Python> script or COBOL or whatever you like instead of trying t= >o foist> preprocessing nastiness on innocent users of high-level Modula-3?>= > > Preprocessing is super nasty. It's not just a question of human> readabi= >lity. m3tk has to be able to read the code, too. I should> be able to write= > a program that reads in (using m3tk) an arbitrary> Modula-3 interface and = >understands it to the point that it can> generate Network Object stubs, int= >er-language call stubs, etc. The> stubs should ALSO be human- and m3tk-read= >able after the transformation!> This should work even if the programmer has= > been very "clever" in> his use of Modula-3 constructs. (Just try getting s= >omething like> that to work with C or C++... it's hopeless once the preproc= >essor> gets involved, and possibly before.)> > Also if I may make a little = >request, if at all possible, please try> not to break binary compatibility = >with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about = >calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--= >_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset= >=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist= > that it depends.> >Putting every platform-specific piece of code in its ow= >n file/directory can=3D> > lead to mass duplication of nearly identical cod= >e.> >Sometimes an #if here or there goes very far in /improving/ code maint= >ainab=3D> >ility.> >A lot of #if here there and everywhere of course can ha= >ve the opposite effe=3D> >ct.> >And I realize if you were to drop support f= >or a target, it is easier to fin=3D> >d/delete files/directories than #ifs,= > but I don't think that's a good enoug=3D> >h reason to sway the decision.>= > >It goes both ways.> >=3D20> >Yes, you could endeavor factor things down s= >o that everything common is in =3D> >common, and everything not-common is i= >n platform-specific. But this is inad=3D> >equate I think. The tail is wagg= >ing the dog unnecessarily I think. If my co=3D> >de very nearly all goes to= >gether, don't make me separate it. Also sometimes=3D> > a different factori= >ng is "encouraged" for other reasons, to match someone =3D> >else's factori= >ng. Look at the C*.i3 files. They actually can be almost all =3D> >be nearl= >y the same, yet they are hardly shared at all. I realize you could =3D> >al= >so do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >=3D> >l the right capabilities for this. Type forwarding, sure. But how abo= >ut pro=3D> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D3D common\ccom= >monstdio.i3 fo=3D> >pen? And having to duplicate a line per type/procedure = >is lame anyway, you =3D> >KIND OF want "module inheritance". However, if yo= >u allow preprocessing base=3D> >d on target, perhaps the need for that goes= > away.> >=3D20> >While extern C varargs functions are generally useless in = >Modula-3, and the=3D> >refore extern __cdecl is fairly rare, it DOES occur = >when you write little h=3D> >elpers in C, such as for errno.> >=3D20> >A go= >od /heuristic/ might be to change the default in any directory that has=3D>= > > no c_source.> >But it is only heuristic.> >=3D20> >Whatever is done here= >, some allowance should probably be made for multiple =3D> >calling convent= >ions in the same file.> >Switching the default to the overwhelming majority= > and then annotating the =3D> >minority is reasonable.> >=3D20> >I still be= >lieve that silently ignoring calling conventions on all but NT386=3D> > is = >VERY reasonable, and that no other platform from here on out will ever =3D>= > >have calling conventions. Esp. not with the same names. When OS/FOO has t= >he=3D> > FOOAPI calling convention, you can just ignore that one on all but= > target =3D> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD p= >ossibly get ug=3D> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();>= > >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >= >The One True Calling Convention for all others, calling convention ignored.= >> >=3D20> >I really believe this is highly highly unlikely to occur, and it= > is not a t=3D> >errible outcome, and this bridge could be crossed in the f= >ar off future.> >The functions that are usually in need of calling conventi= >ons are usually o=3D> >nly present on one system.> >Perhaps ODBC is an extr= >emely rare anomaly and the whole issue is nearly non=3D> >existant.> >That = >could be also.> >A change just for ODBC is probably not the best, though it= > is a very small =3D> >safe harmless change (I always say that :) )> >=3D20= >> >=3D20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.c= >om> From: hosking at cs.purdue.e=3D> >du> Subject: Re: [M3devel] "target speci= >fic pragmas"?> Date: Mon, 11 Feb 20=3D> >08 21:08:46 -0500> To: darko at darko= >.org> > Indeed!> > On Feb 11, 2008, at 8:=3D> >37 PM, Darko wrote:> > > I t= >hink it's not a good idea. I think all platform=3D> > specific code > > sho= >uld be in a separate file. I'd also like to see an op=3D> >tion to > > move= > calling conventions to the makefile rather than in pramas =3D> >to > > avo= >id having to duplicate interface files just to have a different >=3D> > > c= >alling convention for a different platform.> >> > - Darko> >> >> > On 1=3D>= > >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this thro= >ug=3D> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" i= >s a good=3D> > > >> idea.> >>> >> Something like either the ability to pref= >ix pragmas wit=3D> >h a target, > >> or an "iftarget" and "ifnottarget" pra= >gma.> >>> >> Somethi=3D> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* = >END_IF_TARGET*>> >>> >>> >=3D> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGE= >T*>> >> It's a small can of worm=3D> >s.> >> Where can they be placed? Only= > at "global" scope? (ie: toplevel in >=3D> > >> an interface/module).> >>> = >>> What about IF_OSTYPE?> >> What about expr=3D> >essions?> >> IF_TARGET NT= >386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=3D> >> etc.> >>> >> I do= >n't really have enough interest here to work through thi=3D> >s, > >> just = >sending out the bait...> >>> >> Obviously this was triggered b=3D> >y my ha= >ppening into the odbc > >> directory and bringing up ignoring WINAPI=3D> > = >on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >=3D> >This reminds me of an important point here however -- nobody else > >= >> is g=3D> >oing to make the mistake of ever having multiple calling > >> c= >onventions. =3D> >Therefore the generality of prefixing WINAPI with > >> NT= >386: is useless.> =3D> >>> Unless Mac68K support is added.> >>> >> And here= > is some rationale even.=3D> > The PC and Mac evolved from > >> "small" sys= >tems, where assembly programmi=3D> >ng was common, more > >> people knew mo= >re lower level details and playing g=3D> >ames with > >> calling convention= >s was something anyone could do. Most othe=3D> >r > >> current systems are = >rooted in C programming. Working in C, calling >=3D> > >> conventions are g= >enerally in a hidden layer below what anyone > >> thin=3D> >ks about. There= >fore, the smaller number of capable people > >> working at t=3D> >hat level= > have the good sense to only have one calling > >> convention. No =3D> >mor= >e systems will evolve from "small", at least not > >> without having obs=3D= >> >erved this history. Therefore, there will no > >> longer be multiple cal= >lin=3D> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Win= >dows does=3D> > also have __thiscall and __clrcall. __thiscall is > >> only= > x86>=3D20> >______________________________________________________________= >___> >Climb to the top of the charts!=3DA0Play the word scramble challenge = >with sta=3D> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3D3Dst= >arshuffle_wlmailtextlink_ja=3D> >n=3D> >> >--_8b04f633-e2a4-411d-940a-739ab= >79b0616_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Content-Transf= >er-Encoding: quoted-printable> >> >> >> >> >> >e'>I insist that it depends.
> >Putting every platform-specific piece of= > code in its own file/directory can=3D> > lead to mass duplication of nearl= >y identical code.
> >Sometimes an #if here or there goes very far in /im= >proving/ code maintainab=3D> >ility.
> >A lot of #if here there and ever= >ywhere of course can have the opposite effe=3D> >ct.
> >And I realize if= > you were to drop support for a target, it is easier to fin=3D> >d/delete f= >iles/directories than #ifs, but I don't think that's a good enoug=3D> >h re= >ason to sway the decision.
> >It goes both ways.
> > 
> >Yes,= > you could endeavor factor things down so that everything common i=3D>= > >s in common, and everything not-common is in platform-specific. But this = >is=3D> > inadequate I think. The tail is wagging the dog unnecessarily I th= >ink. If =3D> >my code very nearly all goes together, don't make me sep= >arate it. =3D> >;Also sometimes a different factoring is "encouraged" f= >or other reasons, to=3D> > match someone else's factoring. Look at the C*.i= >3 files. They actually can=3D> > be almost all be nearly the same, yet they= > are hardly shared at all. I rea=3D> >lize you could also do a sort of "for= >warding", though I'm not sure that Mod=3D> >ula-3 offers all the right capa= >bilities for this. Type forwarding, sure. Bu=3D> >t how about procedure for= >warding? Like nt386\cstdio.i3 fopen =3D3D common\cco=3D> >mmonstdio.i3 fope= >n? And having to duplicate a line per type/procedure is la=3D> >me anyway, = >you KIND OF want "module inheritance". However, if you allow pre=3D> >proce= >ssing based on target, perhaps the need for that goes away.
> > >> >While extern C varargs functions are generally useless in Modula-3, and= > the=3D> >refore extern __cdecl is fairly rare, it DOES occur when you writ= >e little h=3D> >elpers in C, such as for errno.
> > 
> >A good /= >heuristic/ might be to change the default in any directory that has=3D> > n= >o c_source.
> >But it is only heuristic.
> > 
> >Whatever is = >done here, some allowance should probably be made for multiple =3D> >callin= >g conventions in the same file.
> >Switching the default to the overwhel= >ming majority and then annotating the =3D> >minority is reasonable.
> >&= >nbsp;
> >I still believe that silently ignoring calling conventions on a= >ll but NT386=3D> > is VERY reasonable, and that no other platform from here= > on out will ever =3D> >have calling conventions. Esp. not with the same na= >mes. When OS/FOO has the=3D> > FOOAPI calling convention, you can just igno= >re that one on all but target =3D> >OS/FOO. Just as all but NT386 ignore WI= >NAPI. Yes this COULD possibly get ug=3D> >ly something like:
> ><*EXT= >ERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.>> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention= > for all others, calling convention ignored.=3D> >
> > 
> >I rea= >lly believe this is highly highly unlikely to occur, and it is not a t=3D> = >>errible outcome, and this bridge could be crossed in the far off future.R=3D> >>> >The functions that are usually in need of calling conventions ar= >e usually o=3D> >nly present on one system.
> >Perhaps ODBC is an extrem= >ely rare anomaly and the whole issue is nearly non=3D> >existant.
> >Tha= >t could be also.
> >A change just for ODBC is probably not the best, tho= >ugh it is a very small =3D> >safe harmless change (I always say that :) )R>> > 
> > 
> > - Jay

> >> >
ling>> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> = >From: hosking at c=3D> >s.purdue.edu
> Subject: Re: [M3devel] "target sp= >ecific pragmas"?
&=3D> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
>= >; To: darko at darko.org
&g=3D> >t;
> Indeed!
>
> On Fe= >b 11, 2008, at 8:37 PM, Darko wro=3D> >te:
>
> > I think it= >'s not a good idea. I think all platfor=3D> >m specific code
> > = >should be in a separate file. I'd also like t=3D> >o see an option to
&= >gt; > move calling conventions to the makefile r=3D> >ather than in pram= >as to
> > avoid having to duplicate interface f=3D> >iles just to= > have a different
> > calling convention for a differ=3D> >ent pl= >atform.
> >
> > - Darko
> >
> > >= >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >=3D> >;> So I have NOT thought this through.
> >>
> &g= >t;>=3D> > I wonder if "preprocessing" dependent only on "target" is a go= >od
> =3D> >>> idea.
> >>
> >> Somethin= >g like either the =3D> >ability to prefix pragmas with a target,
> &= >gt;> or an "iftarget"=3D> > and "ifnottarget" pragma.
> >>R>> >> Something like=3D> > so:
> >>
> >> = ><* IF_TARGET NT386 *>
> =3D> >>> <* END_IF_TARGET*>= >
> >>
> >>
>=3D> > >> <* IF_TARGET N= >T386 *>
> >> <* END_IF_TARGET*=3D> >>
> >>= > It's a small can of worms.
> >> Where can=3D> > they be placed= >? Only at "global" scope? (ie: toplevel in
> >>=3D> > an inter= >face/module).
> >>
> >> What about IF_OSTY=3D> >PE?= >
> >> What about expressions?
> >> IF_TARGET NT3=3D= >> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
= >>=3D> >; >>
> >> etc.
> >>
> >>= > I don't =3D> >really have enough interest here to work through this,
&= >gt; >> ju=3D> >st sending out the bait...
> >>
> &g= >t;> Obviously this=3D> > was triggered by my happening into the odbc >> >> directory an=3D> >d bringing up ignoring WINAPI on non-NT386= > or
> >> prefixing c=3D> >alling conventions with a target.>> >>
> >> This re=3D> >minds me of an important point= > here however -- nobody else
> >>=3D> >; is going to make the m= >istake of ever having multiple calling
> >=3D> >;> conventions.= > Therefore the generality of prefixing WINAPI with
&g=3D> >t; >> = >NT386: is useless.
> >> Unless Mac68K support is ad=3D> >ded.R>> >>
> >> And here is some rationale even. The=3D> >= > PC and Mac evolved from
> >> "small" systems, where assembly = >=3D> >programming was common, more
> >> people knew more lower= > level=3D> > details and playing games with
> >> calling conve= >ntions was s=3D> >omething anyone could do. Most other
> >> cu= >rrent systems are =3D> >rooted in C programming. Working in C, calling
= >> >> convention=3D> >s are generally in a hidden layer below what = >anyone
> >> think=3D> >s about. Therefore, the smaller number = >of capable people
> >> =3D> >working at that level have the go= >od sense to only have one calling
>=3D> > >> convention. No mo= >re systems will evolve from "small", at least no=3D> >t
> >> w= >ithout having observed this history. Therefore, there =3D> >will no
>= >; >> longer be multiple calling conventions.
> &=3D> >gt;>R>> >> That is my theory at least.
> >>
&g=3D> >t; = >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall=3D= >> > is
> >> only x86
>


Climb to the = >top=3D> > of the charts!=3DA0Play the word scramble challenge with star pow= >er. >=3D3D'http://club.live.com/star_shuffle.aspx?icid=3D3Dstar= >shuffle_wlmailtextlin=3D> >k_jan' target=3D3D'_new'>Play now!> >= >=3D> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Mika good point, I know that, forgot, thanks for = >reminding me.
>  One of the interesting things about Modula-3, or rather anything but= > C and C++, is easy parsing, easy building of other tools.
> 
>Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the p= >kg tree? You know, they can't understand the source tree without understand= >ing m3makefiles.
> 
>I started a little experiment here.
>I added m3-libs/m3core/src/C/common/Cstdio.i3.
>This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386.
>I'm thinking either:
>   a) I'm not quite on base and just fork it per-target, as it wa= >s
   b) provide a little bit of C code with #ifdefs, like making th= >e SEEK_* constants into VARs and using C to initialize them. That's a bit o= >f a downer though, since constants ought to be constants.
>   c) factor it somehow as I was alluding, like, well, again I'm = >not sure Modula-3 has what I'd want here, but at least for types and consta= >nts, you can push the non-portable stuff into Ctargetstdio.i3 and then expo= >se them in Cstdio.i3, forking only Ctargetstdio.i.
> 
>I'll explain so I can get my question in. :)
> 
>I understand, say:
> 
>Ctargetstdio.i3 (* one of these per target, with not much content *) <= >BR> >CONST
>  SEEK_CUR =3D ..; (* target specific probably *)
>  SEEK_SET =3D ..; ditto
>  SEEK_END =3D ..; ditto 
>TYPE
>  FOO =3D ... ditto 
> 
>Cstdio.i3 (* portable *)
> CONST
>  SEEK_CUR =3D Ctargetstdio.SEEK_CUR;
>  SEEK_SET =3D Ctargetstdio.SEEK_SET;
>  SEEK_END =3D Ctargetstdio.SEEK_END;
>TYPE
>  FOO =3D Ctargetstdio.FOO;
> 
>FILE =3D UNTRACED REF RECORD END;
> 
><extern> procedure fopen(a: const_char_star; b: const_char_star): FIL= >E;
> 
>It is tedious but I believe it works.
>It'd be nice, I think, if every symbol in one interface could be autom= >atically aliases/exposed in another.
>  At least for this purpose, maybe not for any other. I'm speculating = >here, so please respond kindly. :)
>The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place.
> 
>However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another.
>Nevermind for now how you can portably call it.
> 
>Ctargetstdio.i3 (* one of these for every target, but another question in&n= >bsp;a sec ... *)
> 
><extern> PROCEDURE seeksomething(a: off_t);  let's say it is int= > on some platforms.
> 
>Cstdio.i3 (* the portable one *)
> 
>seeksomething =3D Ctargetstdio.seeksomething;    does this w= >ork? I should try it out, read the docs.
> 
>But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int.
>It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants.
>You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE).
>OS_TYPE implies less work, nice.
> 
>Perhaps concatening stuff in arbitrary way with Quake really is the way?> >It seems almost sarcastic, but perhaps not.
> 
>As long as the pkg store is easily parsed?
>(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..)
> 
>But for that matter --- <IF_TARGET> could be processed by the compile= >r and result in a file with it already accounted for and ship that. Isn't t= >hat just as good? EXCEPT that more thought would have to go into the spec, = >whereas m3makefile is already a general purpose system that anyone can do a= >nything with?
> 
>??
> 
> - Jay

> >
>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] "target specific pragmas"?
> Date: Tue, 12 Feb 20= >08 04:56:02 -0800
> From: mika at async.caltech.edu
>
> >> Can you just generate the Modula-3 code you want using a Python
&g= >t; script or COBOL or whatever you like instead of trying to foist
> = >preprocessing nastiness on innocent users of high-level Modula-3?
> <= >BR>> Preprocessing is super nasty. It's not just a question of human
= >> readability. m3tk has to be able to read the code, too. I should
&g= >t; be able to write a program that reads in (using m3tk) an arbitrary
&g= t; Modula-3 interface and understands it to the point that it can
> g= >enerate Network Object stubs, inter-language call stubs, etc. The
> s= >tubs should ALSO be human- and m3tk-readable after the transformation!
&= >gt; This should work even if the programmer has been very "clever" in
&g= >t; his use of Modula-3 constructs. (Just try getting something like
>= > that to work with C or C++... it's hopeless once the preprocessor
> = >gets involved, and possibly before.)
>
> Also if I may make a = >little request, if at all possible, please try
> not to break binary = >compatibility with gcc-compiled C and Fortran
> on NT386GNU (not sure= > if your ideas about calling conventions could
> possibly do that...)= >
>
> Mika
>
> Jay writes:
> >--_8b04f633= >-e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/plain; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> >I insist that it depends.
> >Putting every p= >latform-specific piece of code in its own file/directory can=3D
> >= >; lead to mass duplication of nearly identical code.
> >Sometimes = >an #if here or there goes very far in /improving/ code maintainab=3D
>= >; >ility.
> >A lot of #if here there and everywhere of course c= >an have the opposite effe=3D
> >ct.
> >And I realize if y= >ou were to drop support for a target, it is easier to fin=3D
> >d/= >delete files/directories than #ifs, but I don't think that's a good enoug= >=3D
> >h reason to sway the decision.
> >It goes both way= >s.
> >=3D20
> >Yes, you could endeavor factor things down= > so that everything common is in =3D
> >common, and everything not= >-common is in platform-specific. But this is inad=3D
> >equate I t= >hink. The tail is wagging the dog unnecessarily I think. If my co=3D
>= >; >de very nearly all goes together, don't make me separate it. Also som= >etimes=3D
> > a different factoring is "encouraged" for other reas= >ons, to match someone =3D
> >else's factoring. Look at the C*.i3 f= >iles. They actually can be almost all =3D
> >be nearly the same, y= >et they are hardly shared at all. I realize you could =3D
> >also = >do a sort of "forwarding", though I'm not sure that Modula-3 offers al=3DR>> >l the right capabilities for this. Type forwarding, sure. But ho= >w about pro=3D
> >cedure forwarding? Like nt386\cstdio.i3 fopen = >=3D3D common\ccommonstdio.i3 fo=3D
> >pen? And having to duplicate= > a line per type/procedure is lame anyway, you =3D
> >KIND OF want= > "module inheritance". However, if you allow preprocessing base=3D
> = >>d on target, perhaps the need for that goes away.
> >=3D20
= >> >While extern C varargs functions are generally useless in Modula-3= >, and the=3D
> >refore extern __cdecl is fairly rare, it DOES occu= >r when you write little h=3D
> >elpers in C, such as for errno.>> >=3D20
> >A good /heuristic/ might be to change the defau= >lt in any directory that has=3D
> > no c_source.
> >But i= >t is only heuristic.
> >=3D20
> >Whatever is done here, s= >ome allowance should probably be made for multiple =3D
> >calling = >conventions in the same file.
> >Switching the default to the over= >whelming majority and then annotating the =3D
> >minority is reaso= >nable.
> >=3D20
> >I still believe that silently ignoring= > calling conventions on all but NT386=3D
> > is VERY reasonable, a= >nd that no other platform from here on out will ever =3D
> >have c= >alling conventions. Esp. not with the same names. When OS/FOO has the=3D>> > FOOAPI calling convention, you can just ignore that one on all b= >ut target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes = >this COULD possibly get ug=3D
> >ly something like:
> >&l= >t;*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI= > ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One= > True Calling Convention for all others, calling convention ignored.
>= >; >=3D20
> >I really believe this is highly highly unlikely to = >occur, and it is not a t=3D
> >errible outcome, and this bridge co= >uld be crossed in the far off future.
> >The functions that are us= >ually in need of calling conventions are usually o=3D
> >nly prese= >nt on one system.
> >Perhaps ODBC is an extremely rare anomaly and= > the whole issue is nearly non=3D
> >existant.
> >That co= >uld be also.
> >A change just for ODBC is probably not the best, t= >hough it is a very small =3D
> >safe harmless change (I always say= > that :) )
> >=3D20
> >=3D20
> > - Jay
> &= >gt;
> >
> >
> >> CC: jayk123 at hotmail.com; m3d= >evel at elegosoft.com> From: hosking at cs.purdue.e=3D
> >du> Subj= >ect: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=3DR>> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> &= >gt; On Feb 11, 2008, at 8:=3D
> >37 PM, Darko wrote:> > >= > I think it's not a good idea. I think all platform=3D
> > specifi= >c code > > should be in a separate file. I'd also like to see an op= >=3D
> >tion to > > move calling conventions to the makefile = >rather than in pramas =3D
> >to > > avoid having to duplicat= >e interface files just to have a different >=3D
> > > callin= >g convention for a different platform.> >> > - Darko> >&g= >t; >> > On 1=3D
> >2/02/2008, at 12:21 PM, Jay wrote:>= > >> >> So I have NOT thought this throug=3D
> >h.> = >>>> >> I wonder if "preprocessing" dependent only on "target= >" is a good=3D
> > > >> idea.> >>> >> S= >omething like either the ability to prefix pragmas wit=3D
> >h a t= >arget, > >> or an "iftarget" and "ifnottarget" pragma.> >>= >;> >> Somethi=3D
> >ng like so:> >>> >>= > <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >= >>> >>> >=3D
> >> <* IF_TARGET NT386 *>&= >gt; >> <* END_IF_TARGET*>> >> It's a small can of worm= >=3D
> >s.> >> Where can they be placed? Only at "global" = >scope? (ie: toplevel in >=3D
> > >> an interface/module).= >> >>> >> What about IF_OSTYPE?> >> What about ex= >pr=3D
> >essions?> >> IF_TARGET NT386 OR NTAMD64> >= >>> >> IF_TARGET STARTS(NT)> >>> >=3D
> >= >;> etc.> >>> >> I don't really have enough interest he= >re to work through thi=3D
> >s, > >> just sending out the= > bait...> >>> >> Obviously this was triggered b=3D
>= >; >y my happening into the odbc > >> directory and bringing up = >ignoring WINAPI=3D
> > on non-NT386 or > >> prefixing cal= >ling conventions with a target.> >>> >> =3D
> >T= >his reminds me of an important point here however -- nobody else > >&= >gt; is g=3D
> >oing to make the mistake of ever having multiple ca= >lling > >> conventions. =3D
> >Therefore the generality o= >f prefixing WINAPI with > >> NT386: is useless.> =3D
> &g= >t;>> Unless Mac68K support is added.> >>> >> And he= >re is some rationale even.=3D
> > The PC and Mac evolved from >= > >> "small" systems, where assembly programmi=3D
> >ng was c= >ommon, more > >> people knew more lower level details and playing = >g=3D
> >ames with > >> calling conventions was something = >anyone could do. Most othe=3D
> >r > >> current systems a= >re rooted in C programming. Working in C, calling >=3D
> > >= >> conventions are generally in a hidden layer below what anyone > >= >;> thin=3D
> >ks about. Therefore, the smaller number of capabl= >e people > >> working at t=3D
> >hat level have the good = >sense to only have one calling > >> convention. No =3D
> >= >;more systems will evolve from "small", at least not > >> without = >having obs=3D
> >erved this history. Therefore, there will no >= > >> longer be multiple callin=3D
> >g conventions.> >&= >gt;> >> That is my theory at least.> >>> >> Oh, = >Windows does=3D
> > also have __thiscall and __clrcall. __thiscall= > is > >> only x86>=3D20
> >___________________________= >______________________________________
> >Climb to the top of the = >charts!=3DA0Play the word scramble challenge with sta=3D
> >r powe= >r.
> >http://club.live.com/star_shuffle.aspx?icid=3D3Dstarshuffle_= >wlmailtextlink_ja=3D
> >n=3D
> >
> >--_8b04f633-= >e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/html; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> ><html>
> ><head>
> ><= >;style>
> >.hmmessage P
> >{
> >margin:0px;R>> >padding:0px
> >}
> >body.hmmessage
> >= >;{
> >FONT-SIZE: 10pt;
> >FONT-FAMILY:Tahoma
> >= >}
> ></style>
> ></head>
> ><body= > class=3D3D'hmmessage'>I insist that it depends.<BR>
> >P= >utting every platform-specific piece of code in its own file/directory can= >=3D
> > lead to mass duplication of nearly identical code.<BR&g= >t;
> >Sometimes an #if here or there goes very far in /improving/ = >code maintainab=3D
> >ility.<BR>
> >A lot of #if he= >re there and everywhere of course can have the opposite effe=3D
> >= >;ct.<BR>
> >And I realize if you were to drop support for a = >target, it is easier to fin=3D
> >d/delete files/directories than = >#ifs, but I don't think that's a good enoug=3D
> >h reason to sway= > the decision.<BR>
> >It goes both ways.<BR>
> &= >gt;&nbsp;<BR>
> >Yes, you could endeavor&nbsp;factor= > things down so that everything common i=3D
> >s in common, and ev= >erything not-common is in platform-specific. But this is=3D
> > in= >adequate I think. The tail is wagging the dog unnecessarily I think. If =3D= >
> >my code very nearly all goes together, don't make me&nbsp;= >separate it.&nbsp=3D
> >;Also sometimes a different factoring = >is "encouraged" for other reasons, to=3D
> > match someone else's = >factoring. Look at the C*.i3 files. They actually can=3D
> > be al= >most all be nearly the same, yet they are hardly shared at all. I rea=3D>> >lize you could also do a sort of "forwarding", though I'm not sur= >e that Mod=3D
> >ula-3 offers all the right capabilities for this.= > Type forwarding, sure. Bu=3D
> >t how about procedure forwarding?= > Like nt386\cstdio.i3 fopen =3D3D common\cco=3D
> >mmonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is la=3D
> >= >;me anyway, you KIND OF want "module inheritance". However, if you allow pr= >e=3D
> >processing based on target, perhaps the need for that goes= > away.<BR>
> >&nbsp;<BR>
> >While extern = >C varargs functions are generally useless in Modula-3, and the=3D
> &= >gt;refore extern __cdecl is fairly rare, it DOES occur when you write littl= >e h=3D
> >elpers in C, such as for errno.<BR>
> >&a= >mp;nbsp;<BR>
> >A good /heuristic/ might be to change the de= >fault in any directory that has=3D
> > no c_source.<BR>
&= >gt; >But it is only heuristic.<BR>
> >&nbsp;<BR>= >;
> >Whatever is done here, some allowance should probably be made= > for multiple =3D
> >calling conventions in the same file.<BR&g= >t;
> >Switching the default to the overwhelming majority and then = >annotating the =3D
> >minority is reasonable.<BR>
> &g= >t;&nbsp;<BR>
> >I still believe that silently ignoring c= >alling conventions on all but NT386=3D
> > is VERY reasonable, and= > that no other platform from here on out will ever =3D
> >have cal= >ling conventions. Esp. not with the same names. When OS/FOO has the=3D
&= >gt; > FOOAPI calling convention, you can just ignore that one on all but= > target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes th= is COULD possibly get ug=3D
> >ly something like:<BR>
>= >; >&lt;*EXTERN FOOAPI WINAPI*&gt; fopen();<BR>
> >= >;FOOAPI for OS/FOO, WINAPI ignored.<BR>
> >WINAPI for NT386,= > FOOAPI ignored.<BR>
> >The One True Calling Convention for = >all others, calling convention ignored.=3D
> ><BR>
> &= >gt;&nbsp;<BR>
> >I really believe this is highly highly = >unlikely to occur, and it is not a t=3D
> >errible outcome, and th= >is bridge could be crossed in the far off future.<BR=3D
> >>= >
> >The functions that are usually in need of calling conventions = >are usually o=3D
> >nly present on one system.<BR>
> &= >gt;Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly = >non=3D
> >existant.<BR>
> >That could be also.<B= >R>
> >A change just for ODBC is probably not the best, though i= >t is a very small =3D
> >safe harmless change (I always say that := >) )<BR>
> >&nbsp;<BR>
> >&nbsp;<BR= >>
> >&nbsp;- Jay<BR><BR>
> >
> &= >gt;<HR id=3D3DstopSpelling>
> ><BR>
> >&g= >t; CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>&gt; From: h= >osking at c=3D
> >s.purdue.edu<BR>&gt; Subject: Re: [M3deve= >l] "target specific pragmas"?<BR>&=3D
> >gt; Date: Mon, = >11 Feb 2008 21:08:46 -0500<BR>&gt; To: darko at darko.org<BR>&= >amp;g=3D
> >t; <BR>&gt; Indeed!<BR>&gt; <BR= >>&gt; On Feb 11, 2008, at 8:37 PM, Darko wro=3D
> >te:<B= >R>&gt; <BR>&gt; &gt; I think it's not a good idea. I t= >hink all platfor=3D
> >m specific code <BR>&gt; &gt;= > should be in a separate file. I'd also like t=3D
> >o see an opti= >on to <BR>&gt; &gt; move calling conventions to the makefile = >r=3D
> >ather than in pramas to <BR>&gt; &gt; avoid = >having to duplicate interface f=3D
> >iles just to have a differen= >t <BR>&gt; &gt; calling convention for a differ=3D
> &g= >t;ent platform.<BR>&gt; &gt;<BR>&gt; &gt; - Dar= >ko<BR>&gt; &gt;<BR>&gt; &gt;<B=3D
> &g= >t;R>&gt; &gt; On 12/02/2008, at 12:21 PM, Jay wrote:<BR>&a= >mp;gt; &gt;<BR>&gt; &gt=3D
> >;&gt; So I hav= >e NOT thought this through.<BR>&gt; &gt;&gt;<BR>&am= >p;gt; &gt;&gt;=3D
> > I wonder if "preprocessing" dependen= >t only on "target" is a good <BR>&gt; =3D
> >&gt;&am= >p;gt; idea.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&a= >mp;gt; Something like either the =3D
> >ability to prefix pragmas = >with a target, <BR>&gt; &gt;&gt; or an "iftarget"=3D
&= >gt; > and "ifnottarget" pragma.<BR>&gt; &gt;&gt;<BR= >>&gt; &gt;&gt; Something like=3D
> > so:<BR>&= >amp;gt; &gt;&gt;<BR>&gt; &gt;&gt; &lt;* IF_TA= >RGET NT386 *&gt;<BR>&gt; =3D
> >&gt;&gt; &am= >p;lt;* END_IF_TARGET*&gt;<BR>&gt; &gt;&gt;<BR>&= >amp;gt; &gt;&gt;<BR>&gt;=3D
> > &gt;&gt;= > &lt;* IF_TARGET NT386 *&gt;<BR>&gt; &gt;&gt; &am= >p;lt;* END_IF_TARGET*=3D
> >&gt;<BR>&gt; &gt;&am= >p;gt; It's a small can of worms.<BR>&gt; &gt;&gt; Where c= >an=3D
> > they be placed? Only at "global" scope? (ie: toplevel in= > <BR>&gt; &gt;&gt;=3D
> > an interface/module).&= >lt;BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; What = >about IF_OSTY=3D
> >PE?<BR>&gt; &gt;&gt; What ab= >out expressions?<BR>&gt; &gt;&gt; IF_TARGET NT3=3D
>= >; >86 OR NTAMD64<BR>&gt; &gt;&gt;<BR>&gt; &a= >mp;gt;&gt; IF_TARGET STARTS(NT)<BR>&gt=3D
> >; &= >gt;&gt;<BR>&gt; &gt;&gt; etc.<BR>&gt; &= >gt;&gt;<BR>&gt; &gt;&gt; I don't =3D
> >real= >ly have enough interest here to work through this, <BR>&gt; &= >gt;&gt; ju=3D
> >st sending out the bait...<BR>&gt; = >&gt;&gt;<BR>&gt; &gt;&gt; Obviously this=3D
&g= >t; > was triggered by my happening into the odbc <BR>&gt; &= >;gt;&gt; directory an=3D
> >d bringing up ignoring WINAPI on n= >on-NT386 or <BR>&gt; &gt;&gt; prefixing c=3D
> >= >alling conventions with a target.<BR>&gt; &gt;&gt;<BR&= >gt;&gt; &gt;&gt; This re=3D
> >minds me of an importan= >t point here however -- nobody else <BR>&gt; &gt;&gt=3DR>> >; is going to make the mistake of ever having multiple calling &= >lt;BR>&gt; &gt=3D
> >;&gt; conventions. Therefore t= >he generality of prefixing WINAPI with <BR>&g=3D
> >t; &= >amp;gt;&gt; NT386: is useless.<BR>&gt; &gt;&gt; Unles= >s Mac68K support is ad=3D
> >ded.<BR>&gt; &gt;&g= >t;<BR>&gt; &gt;&gt; And here is some rationale even. The= >=3D
> > PC and Mac evolved from <BR>&gt; &gt;&gt= >; "small" systems, where assembly =3D
> >programming was common, m= >ore <BR>&gt; &gt;&gt; people knew more lower level=3D
= >> > details and playing games with <BR>&gt; &gt;&gt= >; calling conventions was s=3D
> >omething anyone could do. Most o= >ther <BR>&gt; &gt;&gt; current systems are =3D
> &g= >t;rooted in C programming. Working in C, calling <BR>&gt; &gt= >;&gt; convention=3D
> >s are generally in a hidden layer below= > what anyone <BR>&gt; &gt;&gt; think=3D
> >s abo= >ut. Therefore, the smaller number of capable people <BR>&gt; &= >;gt;&gt; =3D
> >working at that level have the good sense to o= >nly have one calling <BR>&gt;=3D
> > &gt;&gt; co= >nvention. No more systems will evolve from "small", at least no=3D
> = >>t <BR>&gt; &gt;&gt; without having observed this hist= >ory. Therefore, there =3D
> >will no <BR>&gt; &gt;&a= >mp;gt; longer be multiple calling conventions.<BR>&gt; &=3DR>> >gt;&gt;<BR>&gt; &gt;&gt; That is my theory= > at least.<BR>&gt; &gt;&gt;<BR>&g=3D
> &g= >t;t; &gt;&gt; Oh, Windows does also have __thiscall and __clrcall. = >__thiscall=3D
> > is <BR>&gt; &gt;&gt; only x86&= >lt;BR>&gt; <BR><BR><br /><hr />Climb to the = >top=3D
> > of the charts!=3DA0Play the word scramble challenge wit= >h star power. <a href=3D
> >=3D3D'http://club.live.com/star_shu= >ffle.aspx?icid=3D3Dstarshuffle_wlmailtextlin=3D
> >k_jan' target= >=3D3D'_new'>Play now!</a></body>
> ></html>= >=3D
> >
> >--_8b04f633-e2a4-411d-940a-739ab79b0616_--
= >

Climb to the top of the charts!=A0Play the word scramble ch= >allenge with star power. icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now! >= > >--_91974b83-e297-4ab9-ba44-e888f600b934_-- From mika at async.caltech.edu Tue Feb 12 22:27:15 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:27:15 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 14:02:23 GMT." Message-ID: <200802122127.m1CLRFi0007370@camembert.async.caltech.edu> Jay writes: >Mika your switch example, besides being invalid C++, is just not fair. >I don't think people even think to write their code like that. >Introducing variables at the top of a switch is rare, esp. initializing the= >m. The example didn't come out of nowhere. I once, a very long time ago, being a not completely competent C programmer, wrote a program like that and spent quite a while debugging it before I realized that the initializations weren't being called. I think I was thinking that initializations are like Fortran DATA statements, or at least should be, in any civilized programming language. If you're extending the stack frame to make room for the declared variables, shouldn't you be calling the initialization code, too? Apparently not... Another way of looking at it is that it was just one of those bizarre little bugs that led me to program in Modula-3. Actually, I remember what finally drove me over the edge. I had written a program to make plots of large VLSI chips at very high resolution (300+ megapixel) using alpha blending, etc., and it was working wonderfully (for years) on FreeBSD. I tried to port it to Linux (trivial, right?) and discovered that I couldn't write a bug-free generic linked list library in C to save my life. The data structures in the program were a bit tricky because of the size of the database, and the fact that I wanted to run it in a small amount of memory. In those days the custom was you had one server with a large amount of RAM (1GB) and a bunch of workstations with 64 or 128 MB. My goal was to run the program, which could take up to a week each time, on the workstations rather than tying up the server (which was busy with other stuff). After I had finally debugged the last memory problem with my program, I sat down and wrote a bug-free one in about two days in Modula-3, a programming language that I previously just vaguely knew as a "fancier Pascal". Mika From dragisha at m3w.org Tue Feb 12 22:24:55 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:24:55 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: <1202851495.3771.3.camel@faramir.m3w.org> This is new project... and it's pretty drafty, meaning it compiles but it does not run. I sumbitted this because it looks like some obscure (underreported?) error to me. Compiler I do use is pretty stable and build lots of my other apps. On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: > Did something change in m3middle/m3front lately? > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > > > % cm3 > > --- building in ../LINUXLIBC6 --- > > > > new source -> compiling Connection.i3 > > new source -> compiling Connection.m3 > > new source -> compiling PDU.i3 > > new source -> compiling PDU.m3 > > "../src/PDU.m3", line 107: warning: not used (len) > > "../src/PDU.m3", line 104: warning: not used (b) > > "../src/PDU.m3", line 116: warning: open array passed by value (o) > > "../src/PDU.m3", line 118: warning: not used (cStr) > > "../src/PDU.m3", line 116: warning: not used (b) > > "../src/PDU.m3", line 116: warning: not used (o) > > "../src/PDU.m3", line 160: warning: not used (c) > > "../src/PDU.m3", line 59: warning: not used (GetInt) > > 8 warnings encountered > > new source -> compiling SMPP.m3 > > "../src/SMPP.m3", line 1: 4 code generation errors > > 1 error encountered > > compilation failed => not building program "smpp" > > Fatal Error: package build failed > > > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From wagner at elegosoft.com Tue Feb 12 23:17:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:17:22 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Message-ID: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Quoting Olaf Wagner : > the builds I started again this morning before leaving home seem to > have succeeded again. I don't understand why compilation with the > latest sources on my own system was broken though; I'll have to > check that tonight. Just one more short followup on this. When I got home, I updated to the latest sources again and ran do-cm3-core.sh. Again, everything compiled, but the executable crashed immediately. I then removed all derived files (realclean) and built again, and this time it worked. So the changes made within the last two days must have touched a subtle dependency of compiler and runtime that the builder does not know or detect. I'd like to understand it better, but it is probably too much effort to isolate all the changes and test them one by one. Sometimes it's just easier to use realclean :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 12 23:22:45 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:22:45 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Quoting Dragi?a Duri? : > This is new project... and it's pretty drafty, meaning it compiles but > it does not run. I sumbitted this because it looks like some obscure > (underreported?) error to me. > > Compiler I do use is pretty stable and build lots of my other apps. > > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >> Did something change in m3middle/m3front lately? >> >> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >> >> > % cm3 >> > --- building in ../LINUXLIBC6 --- [...] >> > "../src/SMPP.m3", line 1: 4 code generation errors >> > 1 error encountered If you could try and post a minimal example that provokes this failure, I'm sure someone on this list can help to solve the problem. Just the lines above provide too little information though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Feb 12 22:35:12 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:35:12 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B1B848.1E75.00D7.1@scires.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> Message-ID: <1202852112.3771.13.camel@faramir.m3w.org> What we _maybe_ can do... is to make some special, preprocessable source form, which some quake command can parse into multiple files in their folders. And these file can be compiled later...Kind of how generic works. But, as current system works, and it does it very well, and as only case where we really need this is Windows... most Unices being or becoming POSIX... I don't see it's smart to spend resources on becoming more C... Esp when "founding fathers" made it so good and so much non-C :). If we really need to make some approach to "their world", it's much better to work on interoperability issues and thus cement our first-class-citizen language status even more. dd On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > Jay: > > My understanding of Modula-3 is that rather than cluttering up the > source code with a bunch of preprocessor directives to deal with the > various changes needed by various platforms, a separate source file is > used for platforms whose implementation must diverge. The m3makefile > is used to control the selection of these platform sources at build > time. I like this approach much better. > > Regards, > Randy > > >>> Jay 2/11/2008 8:21 PM >>> > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, or > an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in an > interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling conventions. > Therefore the generality of prefixing WINAPI with NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew more > lower level details and playing games with calling conventions was > something anyone could do. Most other current systems are rooted in C > programming. Working in C, calling conventions are generally in a > hidden layer below what anyone thinks about. Therefore, the smaller > number of capable people working at that level have the good sense to > only have one calling convention. No more systems will evolve from > "small", at least not without having observed this history. Therefore, > there will no longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 -- Dragi?a Duri? From jayk123 at hotmail.com Tue Feb 12 23:23:30 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:23:30 +0000 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: >From reading the code easily/quickly, this is strange. > > > "../src/SMPP.m3", line 1: 4 code generation errors should be preceded by other sorts of errors. And they all/almost all sound "like internal errors", like assertion failures in m3middle. In particular one of: m3-sys\m3middle\src\M3CG_Check.m3(190):PROCEDURE PutErr (u: U; a, b, c: TEXT := NIL) =m3-sys\m3middle\src\M3CG_Check.m3(194): END PutErr;m3-sys\m3middle\src\M3CG_Check.m3(242): PutErr (self, "bad stack: expected [ ",m3-sys\m3middle\src\M3CG_Check.m3(261): ELSE PutErr (self, "stack overflow");m3-sys\m3middle\src\M3CG_Check.m3(274): PutErr (self, "non-empty stack: ", Stack_Dump (self));m3-sys\m3middle\src\M3CG_Check.m3(382): PutErr (self, "redefined runtime proc: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(391): PutErr (self, "redefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(400): PutErr (self, "undefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(410): PutErr (self, "NIL variable");m3-sys\m3middle\src\M3CG_Check.m3(432): PutErr (self, "temporary reused while live!");m3-sys\m3middle\src\M3CG_Check.m3(446): PutErr (self, "temp freed twice");m3-sys\m3middle\src\M3CG_Check.m3(458): PutErr (self, "nested static initialization");m3-sys\m3middle\src\M3CG_Check.m3(470): ELSE PutErr (self, "missing begin_init");m3-sys\m3middle\src\M3CG_Check.m3(477): IF (self.in_init <= 0) THEN PutErr (self, "missing begin_init") END;m3-sys\m3middle\src\M3CG_Check.m3(480): ELSE PutErr (self, "decreasing offsets");m3-sys\m3middle\src\M3CG_Check.m3(532): PutErr (self, "NIL procedure");m3-sys\m3middle\src\M3CG_Check.m3(540): PutErr (self, "nested procedure declaration");m3-sys\m3middle\src\M3CG_Check.m3(551): ELSE PutErr (self, "missing begin_procedure");m3-sys\m3middle\src\M3CG_Check.m3(554): PutErr (self, "missing end_blocks: ", Int (self.block_count));m3-sys\m3middle\src\M3CG_Check.m3(562): PutErr (self, "temp not freed, created on line ", Int (line));m3-sys\m3middle\src\M3CG_Check.m3(574): PutErr (self, "begin_block not in procedure");m3-sys\m3middle\src\M3CG_Check.m3(586): ELSE PutErr (self, "missing begin_block");m3-sys\m3middle\src\M3CG_Check.m3(604): PutErr (self, "undefined label: ", Int (l));m3-sys\m3middle\src\M3CG_Check.m3(716): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(724): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(739): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(747): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(775): PutErr (self, "floating-point literal doesn't match type");m3-sys\m3middle\src\M3CG_Check.m3(1231): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1242): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1251): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1260): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1268): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1279): ELSE PutErr (self, "missing start_call");34 occurrence(s) have been found. - Jay > From: dragisha at m3w.org> To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 22:24:55 +0100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] wtf "code generation errors"?> > This is new project... and it's pretty drafty, meaning it compiles but> it does not run. I sumbitted this because it looks like some obscure> (underreported?) error to me.> > Compiler I do use is pretty stable and build lots of my other apps.> > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote:> > Did something change in m3middle/m3front lately?> > > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote:> > > > > % cm3> > > --- building in ../LINUXLIBC6 ---> > >> > > new source -> compiling Connection.i3> > > new source -> compiling Connection.m3> > > new source -> compiling PDU.i3> > > new source -> compiling PDU.m3> > > "../src/PDU.m3", line 107: warning: not used (len)> > > "../src/PDU.m3", line 104: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: open array passed by value (o)> > > "../src/PDU.m3", line 118: warning: not used (cStr)> > > "../src/PDU.m3", line 116: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: not used (o)> > > "../src/PDU.m3", line 160: warning: not used (c)> > > "../src/PDU.m3", line 59: warning: not used (GetInt)> > > 8 warnings encountered> > > new source -> compiling SMPP.m3> > > "../src/SMPP.m3", line 1: 4 code generation errors> > > 1 error encountered> > > compilation failed => not building program "smpp"> > > Fatal Error: package build failed> > >> > > -- > > > Dragi?a Duri? > > > -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:26:57 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:26:57 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some. Does it happen on birch? Or only FreeBSD? I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this. Ideally it happens on birch, much quicker for me to get into. Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:30:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:30:23 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: I'm still left wondering -- these other language tools -- you run them over the pkg store's shipped implementation files, right? Or at least check the BUILD_DIR for derived *3 files? Or do the tools, like, ignore missing implementations or other "small" problems? If the "forwarding" shown works, that goes very far in solving this problem without stepping on other language tools (again though, depending somewhat on the first question -- except, I just remembered -- a lot of these tools only need the *.i3 files and not the *.m3 files?) - Jay > Subject: Re: [M3devel] "target specific pragmas"?> From: dragisha at m3w.org> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> Date: Tue, 12 Feb 2008 22:35:12 +0100> > What we _maybe_ can do... is to make some special, preprocessable source> form, which some quake command can parse into multiple files in their> folders. And these file can be compiled later...Kind of how generic> works. > > But, as current system works, and it does it very well, and as only case> where we really need this is Windows... most Unices being or becoming> POSIX... I don't see it's smart to spend resources on becoming more C...> Esp when "founding fathers" made it so good and so much non-C :).> > If we really need to make some approach to "their world", it's much> better to work on interoperability issues and thus cement our> first-class-citizen language status even more.> > dd> > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > Jay:> > > > My understanding of Modula-3 is that rather than cluttering up the> > source code with a bunch of preprocessor directives to deal with the> > various changes needed by various platforms, a separate source file is> > used for platforms whose implementation must diverge. The m3makefile> > is used to control the selection of these platform sources at build> > time. I like this approach much better.> > > > Regards,> > Randy> > > > >>> Jay 2/11/2008 8:21 PM >>>> > So I have NOT thought this through.> > > > I wonder if "preprocessing" dependent only on "target" is a good idea.> > > > Something like either the ability to prefix pragmas with a target, or> > an "iftarget" and "ifnottarget" pragma.> > > > Something like so:> > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > > > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > It's a small can of worms.> > Where can they be placed? Only at "global" scope? (ie: toplevel in an> > interface/module).> > > > What about IF_OSTYPE?> > What about expressions?> > IF_TARGET NT386 OR NTAMD64> > > > IF_TARGET STARTS(NT)> > > > etc.> > > > I don't really have enough interest here to work through this, just> > sending out the bait...> > > > Obviously this was triggered by my happening into the odbc directory> > and bringing up ignoring WINAPI on non-NT386 or prefixing calling> > conventions with a target.> > > > This reminds me of an important point here however -- nobody else is> > going to make the mistake of ever having multiple calling conventions.> > Therefore the generality of prefixing WINAPI with NT386: is useless.> > Unless Mac68K support is added.> > > > And here is some rationale even. The PC and Mac evolved from "small"> > systems, where assembly programming was common, more people knew more> > lower level details and playing games with calling conventions was> > something anyone could do. Most other current systems are rooted in C> > programming. Working in C, calling conventions are generally in a> > hidden layer below what anyone thinks about. Therefore, the smaller> > number of capable people working at that level have the good sense to> > only have one calling convention. No more systems will evolve from> > "small", at least not without having observed this history. Therefore,> > there will no longer be multiple calling conventions.> > > > That is my theory at least.> > > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is> > only x86> -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:33:34 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:33:34 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Olaf, Oh, upon closer read, things are ok now? This could still be somehow attributed to my "VAL" change? And once realclean once, build repeatedly, and it never comes back? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 22:26:57 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some.Does it happen on birch? Or only FreeBSD?I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this.Ideally it happens on birch, much quicker for me to get into.Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 23:52:21 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:52:21 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <20080212235221.3l9sf3f9c088gw04@mail.elegosoft.com> Quoting Jay : > Olaf, Oh, upon closer read, things are ok now? This could still be > somehow attributed to my "VAL" change? > And once realclean once, build repeatedly, and it never comes back? It's all ok now, though we have introduced some incompatibility somewhere, and the builder can't find it. It shows up in other errors when trying to build the whole set of packages, for example: === package m3-ui/mgkit === +++ cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ --- building in FreeBSD4 --- Fatal Error: bad version stamps: PlttFrnds.i3 inconsistent opaque object info for type _t1541f475 super type: _te422a136 data: (size: 32, align: 32) method: (size: 0) => PlttFrnds.i3 super type: _te422a136 data: (size: 64, align: 32) method: (size: 0) => RectsVBT.i3 *** execution of cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' failed *** Ideally, such things shouldn't happen with M3, but I'm pretty sure the package will compile from scratch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 00:54:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:54:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: My principle concern is that once we provide C APIs then C will permeate the M3 space more pervasively (both apps and libraries). What happens when I want to bring up a system where there is no C?!?! Consider the SPIN OS perhaps... Maybe I am just being overly fusty... On Feb 12, 2008, at 4:35 PM, Dragi?a Duri? wrote: > What we _maybe_ can do... is to make some special, preprocessable > source > form, which some quake command can parse into multiple files in their > folders. And these file can be compiled later...Kind of how generic > works. > > But, as current system works, and it does it very well, and as only > case > where we really need this is Windows... most Unices being or becoming > POSIX... I don't see it's smart to spend resources on becoming more > C... > Esp when "founding fathers" made it so good and so much non-C :). > > If we really need to make some approach to "their world", it's much > better to work on interoperability issues and thus cement our > first-class-citizen language status even more. > > dd > > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >> Jay: >> >> My understanding of Modula-3 is that rather than cluttering up the >> source code with a bunch of preprocessor directives to deal with the >> various changes needed by various platforms, a separate source >> file is >> used for platforms whose implementation must diverge. The m3makefile >> is used to control the selection of these platform sources at build >> time. I like this approach much better. >> >> Regards, >> Randy >> >>>>> Jay 2/11/2008 8:21 PM >>> >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, or >> an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in an >> interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, just >> sending out the bait... >> >> Obviously this was triggered by my happening into the odbc directory >> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >> conventions with a target. >> >> This reminds me of an important point here however -- nobody else is >> going to make the mistake of ever having multiple calling >> conventions. >> Therefore the generality of prefixing WINAPI with NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from "small" >> systems, where assembly programming was common, more people knew more >> lower level details and playing games with calling conventions was >> something anyone could do. Most other current systems are rooted in C >> programming. Working in C, calling conventions are generally in a >> hidden layer below what anyone thinks about. Therefore, the smaller >> number of capable people working at that level have the good sense to >> only have one calling convention. No more systems will evolve from >> "small", at least not without having observed this history. >> Therefore, >> there will no longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Feb 13 00:56:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:56:31 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Message-ID: <15AF5E94-4440-450A-BFC4-9553CEB25A03@cs.purdue.edu> Certainly, anything provoking an m3middle error of this kind needs fixing. Can we see a code fragment (and preferably a compilable test case) that generates this error? On Feb 12, 2008, at 5:22 PM, Olaf Wagner wrote: > Quoting Dragi?a Duri? : >> This is new project... and it's pretty drafty, meaning it compiles >> but >> it does not run. I sumbitted this because it looks like some obscure >> (underreported?) error to me. >> >> Compiler I do use is pretty stable and build lots of my other apps. >> >> On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >>> Did something change in m3middle/m3front lately? >>> >>> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >>> >>> > % cm3 >>> > --- building in ../LINUXLIBC6 --- > [...] >>> > "../src/SMPP.m3", line 1: 4 code generation errors >>> > 1 error encountered > > If you could try and post a minimal example that provokes this > failure, I'm sure someone on this list can help to solve the problem. > Just the lines above provide too little information though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Wed Feb 13 00:57:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:57:19 -0500 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <562DD220-6570-4F79-85D9-85F74092A9F9@cs.purdue.edu> I am betting the change to MUTEX definition broke depedent code. On Feb 12, 2008, at 5:17 PM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> the builds I started again this morning before leaving home seem to >> have succeeded again. I don't understand why compilation with the >> latest sources on my own system was broken though; I'll have to >> check that tonight. > > Just one more short followup on this. When I got home, I updated > to the latest sources again and ran do-cm3-core.sh. Again, everything > compiled, but the executable crashed immediately. I then removed > all derived files (realclean) and built again, and this time it > worked. So the changes made within the last two days must have > touched a subtle dependency of compiler and runtime that the builder > does not know or detect. I'd like to understand it better, but it is > probably too much effort to isolate all the changes and test them > one by one. Sometimes it's just easier to use realclean :-/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 01:37:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 16:37:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 18:54:50 EST." Message-ID: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> This is also an excellent reason not to permit "interfaces" to C code inlined into MODULEs. Interfaces are the contract that the implementation has to live up to. Ok, so it happens that under operating system X on architecture Y, the easiest way to implement the interface is to call a C function that "just happens" to have the correct interface. But on another system, which either isn't built in C or where the function doesn't exist, it might be convenient to implement the interface in (gasp!) Modula-3! (I use this pattern as follows: on systems where Intel's Fortran compiler is available, compile from assembly (which was generated by ifort). On other systems, the code is implemented in Modula-3.) Mika Tony Hosking writes: >My principle concern is that once we provide C APIs then C will >permeate the M3 space more pervasively (both apps and libraries). >What happens when I want to bring up a system where there is no >C?!?! Consider the SPIN OS perhaps... > >Maybe I am just being overly fusty... > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > >> What we _maybe_ can do... is to make some special, preprocessable >> source >> form, which some quake command can parse into multiple files in their >> folders. And these file can be compiled later...Kind of how generic >> works. >> >> But, as current system works, and it does it very well, and as only >> case >> where we really need this is Windows... most Unices being or becoming >> POSIX... I don't see it's smart to spend resources on becoming more >> C... >> Esp when "founding fathers" made it so good and so much non-C :). >> >> If we really need to make some approach to "their world", it's much >> better to work on interoperability issues and thus cement our >> first-class-citizen language status even more. >> >> dd >> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >>> Jay: >>> >>> My understanding of Modula-3 is that rather than cluttering up the >>> source code with a bunch of preprocessor directives to deal with the >>> various changes needed by various platforms, a separate source >>> file is >>> used for platforms whose implementation must diverge. The m3makefile >>> is used to control the selection of these platform sources at build >>> time. I like this approach much better. >>> >>> Regards, >>> Randy >>> >>>>>> Jay 2/11/2008 8:21 PM >>> >>> So I have NOT thought this through. >>> >>> I wonder if "preprocessing" dependent only on "target" is a good >>> idea. >>> >>> Something like either the ability to prefix pragmas with a target, or >>> an "iftarget" and "ifnottarget" pragma. >>> >>> Something like so: >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> It's a small can of worms. >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an >>> interface/module). >>> >>> What about IF_OSTYPE? >>> What about expressions? >>> IF_TARGET NT386 OR NTAMD64 >>> >>> IF_TARGET STARTS(NT) >>> >>> etc. >>> >>> I don't really have enough interest here to work through this, just >>> sending out the bait... >>> >>> Obviously this was triggered by my happening into the odbc directory >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >>> conventions with a target. >>> >>> This reminds me of an important point here however -- nobody else is >>> going to make the mistake of ever having multiple calling >>> conventions. >>> Therefore the generality of prefixing WINAPI with NT386: is useless. >>> Unless Mac68K support is added. >>> >>> And here is some rationale even. The PC and Mac evolved from "small" >>> systems, where assembly programming was common, more people knew more >>> lower level details and playing games with calling conventions was >>> something anyone could do. Most other current systems are rooted in C >>> programming. Working in C, calling conventions are generally in a >>> hidden layer below what anyone thinks about. Therefore, the smaller >>> number of capable people working at that level have the good sense to >>> only have one calling convention. No more systems will evolve from >>> "small", at least not without having observed this history. >>> Therefore, >>> there will no longer be multiple calling conventions. >>> >>> That is my theory at least. >>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >>> only x86 >> -- >> Dragi??a Duri?? From jayk123 at hotmail.com Wed Feb 13 05:28:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 04:28:41 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix?There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 16:37:43 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > > This is also an excellent reason not to permit "interfaces" to C> code inlined into MODULEs.> > Interfaces are the contract that the implementation has to live up> to. Ok, so it happens that under operating system X on architecture> Y, the easiest way to implement the interface is to call a C function> that "just happens" to have the correct interface. But on another> system, which either isn't built in C or where the function doesn't> exist, it might be convenient to implement the interface in (gasp!)> Modula-3!> > (I use this pattern as follows: on systems where Intel's Fortran> compiler is available, compile from assembly (which was generated> by ifort). On other systems, the code is implemented in Modula-3.)> > Mika> > Tony Hosking writes:> >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps...> >> >Maybe I am just being overly fusty...> >> >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> >> >> What we _maybe_ can do... is to make some special, preprocessable > >> source> >> form, which some quake command can parse into multiple files in their> >> folders. And these file can be compiled later...Kind of how generic> >> works.> >>> >> But, as current system works, and it does it very well, and as only > >> case> >> where we really need this is Windows... most Unices being or becoming> >> POSIX... I don't see it's smart to spend resources on becoming more > >> C...> >> Esp when "founding fathers" made it so good and so much non-C :).> >>> >> If we really need to make some approach to "their world", it's much> >> better to work on interoperability issues and thus cement our> >> first-class-citizen language status even more.> >>> >> dd> >>> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> >>> Jay:> >>>> >>> My understanding of Modula-3 is that rather than cluttering up the> >>> source code with a bunch of preprocessor directives to deal with the> >>> various changes needed by various platforms, a separate source > >>> file is> >>> used for platforms whose implementation must diverge. The m3makefile> >>> is used to control the selection of these platform sources at build> >>> time. I like this approach much better.> >>>> >>> Regards,> >>> Randy> >>>> >>>>>> Jay 2/11/2008 8:21 PM >>>> >>> So I have NOT thought this through.> >>>> >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea.> >>>> >>> Something like either the ability to prefix pragmas with a target, or> >>> an "iftarget" and "ifnottarget" pragma.> >>>> >>> Something like so:> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>>> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>> It's a small can of worms.> >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an> >>> interface/module).> >>>> >>> What about IF_OSTYPE?> >>> What about expressions?> >>> IF_TARGET NT386 OR NTAMD64> >>>> >>> IF_TARGET STARTS(NT)> >>>> >>> etc.> >>>> >>> I don't really have enough interest here to work through this, just> >>> sending out the bait...> >>>> >>> Obviously this was triggered by my happening into the odbc directory> >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling> >>> conventions with a target.> >>>> >>> This reminds me of an important point here however -- nobody else is> >>> going to make the mistake of ever having multiple calling > >>> conventions.> >>> Therefore the generality of prefixing WINAPI with NT386: is useless.> >>> Unless Mac68K support is added.> >>>> >>> And here is some rationale even. The PC and Mac evolved from "small"> >>> systems, where assembly programming was common, more people knew more> >>> lower level details and playing games with calling conventions was> >>> something anyone could do. Most other current systems are rooted in C> >>> programming. Working in C, calling conventions are generally in a> >>> hidden layer below what anyone thinks about. Therefore, the smaller> >>> number of capable people working at that level have the good sense to> >>> only have one calling convention. No more systems will evolve from> >>> "small", at least not without having observed this history. > >>> Therefore,> >>> there will no longer be multiple calling conventions.> >>>> >>> That is my theory at least.> >>>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is> >>> only x86> >> -- > >> Dragi??a Duri?? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:18:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:18:24 +0000 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: >> And I think we should fix it so that that the symbols have full source paths. >> I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. My experience using gdb suggests that the symbols have paths like foo.m3 and/or ../bar.i3 but never "full paths". You can tell gdb where to look for files, it isn't that hard, and it works. However I would really like the paths to be full paths and gdb to automatically show the source. (I'd also like a mode that shows no source and only assembly, switching off and on, presumably I'll find this in the gdb docs; it's pretty stinky that in the absence of source, you have to tell it display/i $pc but oh well...) Now, 1) Do people mind their full paths "leaking" out in binaries they give people? Make the behavior an option here? 2) When such binaries are moved across machines, presumably you are back roughly where you started. Ok. And then the same "fix"? Or does the full paths defeat any sort of search in provided paths? (It's pretty obvious where this leads if you think about the implementation -- they can look for leaf path elements in a list of directories, and they can be super aggressive and do something iterative where they try cutting off an element at a time from the start of the path and append that to each "search path", and furthermore, they can "remember" which prefixes' removal tended to work and skip right to that, however that could also lead to missing other matches, and this all rapidly explodes into many probes for files and not clearly worth it; I've never implemented a debugger but I've been a greedy/whiny user. :) ) I have not at all looked into this but I assume once I do it's not that difficult to fix. It's probably a matter of a small number of strategically placed calls to get the full path to a file. There will be the inevitable issues with the two or more different path syntaxes (essentially, mingwin and cygwin have different syntaxes, though you can setup symlinks easily enough to make them able to share each other's paths). I don't know if it plays into any "fingerprinting", and if so, that could be a total deal breaker. I kind of expect it does not. Not in anything people expect to read/write into pickles. Could be that switching this causes a rebuild of everything. Could be the full and relative paths are needed, like for cm3 -ship to work or something, or for the resulting shipped .m3exports files to work. Could be some of the builtin very well hidden stuff, the quake functions that .m3exports files use need an extra parameter, but maybe not. You know, as long as only m3cg/as get the changed paths and nothing else does... - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:38:17 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:38:17 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: done hours ago, not sure I saw the commitI still find a bit unsatisfactory.. but I guess that's plenty good. :) - Jay > From: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 12:54:15 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay, I *really* dislike the idea that you are putting target-specific > code in a subdirectory labeled Common!> > If I want to search for target-specific stuff I grep for directories > labeled by that target.> > Please, please, please think about the global picture before making > these sorts of local changes!> > Please back this change out and put this where it belongs in cm3/m3- > libs/m3core/src/C/NT386. I am happy to do it for you but I have > other things to do with my time!> > On Feb 12, 2008, at 2:05 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/02/12 14:05:18> >> > Modified files:> > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c> >> > Log message:> > fix (NT386 only)> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:03 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I don't disagree much or care much. But I like seeing my name in lights. :) - Jay > CC: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: $Id$ ?> Date: Tue, 12 Feb 2008 12:43:53 -0500> To: jayk123 at hotmail.com> > The log tells the story much better than random comments in the code.> > On Feb 12, 2008, at 1:18 AM, Jay wrote:> > > I added some files a while ago and someone either complained or > > added them, so I've been adding them since.> >> > - Jay> >> >> > > Date: Tue, 12 Feb 2008 05:20:47 +0000> > > To: m3commit at elegosoft.com> > > From: hosking at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: hosking at birch. 08/02/12 05:20:47> > >> > > Modified files:> > > cm3/m3-sys/cm3/src/: m3makefile> > >> > > Log message:> > > Let's avoid RCS id stuff shall we. Just clutters up the files...> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:55 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:55 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: Sounds good to me! - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] externs in modules instead of interfaces?> Date: Tue, 12 Feb 2008 12:42:57 -0500> To: jayk123 at hotmail.com> > The globals are gross, and not available on other platforms. Let's > just drop them...> > On Feb 12, 2008, at 12:21 PM, Jay wrote:> > > I think I just said this over the weekend, but really, I should be > > able to put in modules and not be forced to put them in an > > interface.> > Look at the cygwin Utime.i3/m3/C.c for example...> > Yeah, it's a workaround, that I'd like to remove, but it could > > easily represent a non-workaround..> > There's no real "interface/module" here, it's just that I wrote > > some of the code in C.> >> > sorry to be such an annoying whiner..but I ran into this multiple > > times over a short span of time...> >> > - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 12:01:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 11:01:51 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> References: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Message-ID: > From: hosking at cs.purdue.edu> > Aren't these all superseded by gettimeofday?> > I say just not support the global variable access.> > Utime.i3 on other platforms does not have these globals. Could be. I don't know this stuff.. They are currently used though. I didn't happen here by chance.. I'll maybe poke around. I guess this is a time to send diffs and get sign off on all platforms. OR fork the file backwards to DateLinuxOld.m3, DateBsdOld.m3, move everyone to it, then fix DateLinux/Bsd to have no data and as people test their platform move forward? And the last guy turn off the lights? (This is a philosophical and real question. The first approach is slower but moves cleanly all at once from good to good. The second approach allows a gradual migration that starts right away and leaves a cluttered history in its wake but arrives at the same place, possibly but not necessarily sooner.) Anyway, my workaround I think is working.. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 13 14:53:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:53:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <7EF4EBB4-D4F2-4964-80C0-78576D0C9812@cs.purdue.edu> On Feb 12, 2008, at 11:28 PM, Jay wrote: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. I think you will meet strong resistance here for precisely the opposite reason that you are arguing. If you want C write in C. From hosking at cs.purdue.edu Wed Feb 13 14:55:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:55:20 -0500 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: These behaviors are derivative of the GNU tools, not CM3 per se. The munged names are understood by m3gdb, which uses them to obtain type information. You don't see the munged name in m3gdb. On Feb 13, 2008, at 5:18 AM, Jay wrote: > >> And I think we should fix it so that that the symbols have full > source paths. > >> I realize they would only be correct on one machine, and > hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and > it works. > > However I would really like the paths to be full paths and gdb to > automatically show the source. > (I'd also like a mode that shows no source and only assembly, > switching off and on, presumably I'll find this in the gdb docs; > it's pretty stinky that in the absence of source, you have to tell > it display/i $pc but oh well...) > > Now, > 1) Do people mind their full paths "leaking" out in binaries they > give people? > Make the behavior an option here? > > 2) When such binaries are moved across machines, presumably you are > back roughly where you started. Ok. > And then the same "fix"? Or does the full paths defeat any sort of > search in provided paths? > (It's pretty obvious where this leads if you think about the > implementation -- they can look for leaf path elements in a list of > directories, and they can be super aggressive and do something > iterative where they try cutting off an element at a time from the > start of the path and append that to each "search path", and > furthermore, they can "remember" which prefixes' removal tended to > work and skip right to that, however that could also lead to > missing other matches, and this all rapidly explodes into many > probes for files and not clearly worth it; I've never implemented a > debugger but I've been a greedy/whiny user. :) ) > > I have not at all looked into this but I assume once I do it's not > that difficult to fix. > It's probably a matter of a small number of strategically placed > calls to get the full path to a file. > There will be the inevitable issues with the two or more different > path syntaxes (essentially, mingwin and cygwin have different > syntaxes, though you can setup symlinks easily enough to make them > able to share each other's paths). > > I don't know if it plays into any "fingerprinting", and if so, that > could be a total deal breaker. > I kind of expect it does not. Not in anything people expect to read/ > write into pickles. > Could be that switching this causes a rebuild of everything. > Could be the full and relative paths are needed, like for cm3 -ship > to work or something, or for the resulting shipped .m3exports files > to work. Could be some of the builtin very well hidden stuff, the > quake functions that .m3exports files use need an extra parameter, > but maybe not. You know, as long as only m3cg/as get the changed > paths and nothing else does... > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From wagner at elegosoft.com Wed Feb 13 14:58:28 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 14:58:28 +0100 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: <20080213145828.npvgox31w8g8k8sw@mail.elegosoft.com> Quoting Jay : > >> And I think we should fix it so that that the symbols have full > source paths. >> I realize they would only be correct on one > machine, and hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and it works. What exactly is the full path of a module? That of your private workspace (assuming you are using overrides for everything) or that in the global package pool (/usr/local/cm3/pkg/...)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 18:44:31 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 13 Feb 2008 12:44:31 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B2E62D.1E75.00D7.1@scires.com> Jay: I don't want to be offensive, but quite frankly I'm tired of continually reading your gripes about Modula-3 as a language and your pining for C. This forum is for those people interested in advancing the state of Modula-3. We don't care about C/C++/C#/etc in this forum. Those of us who are M3 zealots for the most part probably would welcome any move to divest CM3 of all underpinnings from the C world. Have you seriously studied the Modula-3 language and used it to build production software? I think some of your comments suggest that you are not a true Modula-3 programmer and that you still cling to the C-way of doing things rather than embracing the Modula-3 way. Now, I do think that most people are interested in improving things and no language is perfect, so any well-thought-out proposal for a change to the language is welcome for consideration, But in this mail list forum, I for one would appreciate less ranting about C and more constructive Modula-3. Truly, I do not want to offend you. Maybe I'm just having a bad day, but I encourage you to try and focus your posts to the advancement of Modula-3. Regards, Randy >>> Jay 2/12/2008 11:28 PM >>> > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix? There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu > Date: Tue, 12 Feb 2008 16:37:43 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "target specific pragmas"? > > > This is also an excellent reason not to permit "interfaces" to C > code inlined into MODULEs. > > Interfaces are the contract that the implementation has to live up > to. Ok, so it happens that under operating system X on architecture > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another > system, which either isn't built in C or where the function doesn't > exist, it might be convenient to implement the interface in (gasp!) > Modula-3! > > (I use this pattern as follows: on systems where Intel's Fortran > compiler is available, compile from assembly (which was generated > by ifort). On other systems, the code is implemented in Modula-3.) > > Mika > > Tony Hosking writes: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps... > > > >Maybe I am just being overly fusty... > > > >On Feb 12, 2008, at 4:35 PM, Dragi?*a Duri?* wrote: > > > >> What we _maybe_ can do... is to make some special, preprocessable > >> source > >> form, which some quake command can parse into multiple files in their > >> folders. And these file can be compiled later...Kind of how generic > >> works. > >> > >> But, as current system works, and it does it very well, and as only > >> case > >> where we really need this is Windows... most Unices being or becoming > >> POSIX... I don't see it's smart to spend resources on becoming more > >> C... > >> Esp when "founding fathers" made it so good and so much non-C :). > >> > >> If we really need to make some approach to "their world", it's much > >> better to work on interoperability issues and thus cement our > >> first-class-citizen language status even more. > >> > >> dd > >> > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > >>> Jay: > >>> > >>> My understanding of Modula-3 is that rather than cluttering up the > >>> source code with a bunch of preprocessor directives to deal with the > >>> various changes needed by various platforms, a separate source > >>> file is > >>> used for platforms whose implementation must diverge. The m3makefile > >>> is used to control the selection of these platform sources at build > >>> time. I like this approach much better. > >>> > >>> Regards, > >>> Randy > >>> > >>>>>> Jay 2/11/2008 8:21 PM >>> > >>> So I have NOT thought this through. > >>> > >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea. > >>> > >>> Something like either the ability to prefix pragmas with a target, or > >>> an "iftarget" and "ifnottarget" pragma. > >>> > >>> Something like so: > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> It's a small can of worms. > >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an > >>> interface/module). > >>> > >>> What about IF_OSTYPE? > >>> What about expressions? > >>> IF_TARGET NT386 OR NTAMD64 > >>> > >>> IF_TARGET STARTS(NT) > >>> > >>> etc. > >>> > >>> I don't really have enough interest here to work through this, just > >>> sending out the bait... > >>> > >>> Obviously this was triggered by my happening into the odbc directory > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling > >>> conventions with a target. > >>> > >>> This reminds me of an important point here however -- nobody else is > >>> going to make the mistake of ever having multiple calling > >>> conventions. > >>> Therefore the generality of prefixing WINAPI with NT386: is useless. > >>> Unless Mac68K support is added. > >>> > >>> And here is some rationale even. The PC and Mac evolved from "small" > >>> systems, where assembly programming was common, more people knew more > >>> lower level details and playing games with calling conventions was > >>> something anyone could do. Most other current systems are rooted in C > >>> programming. Working in C, calling conventions are generally in a > >>> hidden layer below what anyone thinks about. Therefore, the smaller > >>> number of capable people working at that level have the good sense to > >>> only have one calling convention. No more systems will evolve from > >>> "small", at least not without having observed this history. > >>> Therefore, > >>> there will no longer be multiple calling conventions. > >>> > >>> That is my theory at least. > >>> > >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >>> only x86 > >> -- > >> Dragi?*a Duri?* Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Feb 13 19:04:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 13 Feb 2008 12:04:15 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B3311F.4070507@wichita.edu> I haven't tried building it on any form of Windows in a long time, but m3gdb accepts unmangled Modula-3 variable (and procedure and type) names, starting with a module or interface name and supplying a fully- qualified path outside-in with procedure names and anonymous block numbers. Or, if you are stopped at a spot in the code, it will look up unqualified, unmangled names using the language's scope rules from the current point. (Hence my concern about having static links stored.) From there, you can put on additional qualifiers. Naming executable points in the code (e.g. to set breakpoints) works similarly, although that is somewhat different, and obviously, variable names aren't meaningful here. It doesn't accept paths in the filesystem, though. I'm not sure I think that would be a good idea, as it is really mostly finding things in the executable program, not the source code. It also doesn't find constant or exception names, as these currently produce no debug information. Perhaps it is time for me to modify the m3gdb web page, and also see if m3gdb can be built in Windows. Jay wrote: > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full source > paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > -- ------------------------------------------------------------- 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 Wed Feb 13 22:38:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 22:38:04 +0100 Subject: [M3devel] "Microlocation" In-Reply-To: <1202893163.3771.33.camel@faramir.m3w.org> References: <1202893163.3771.33.camel@faramir.m3w.org> Message-ID: <20080213223804.jkey99zegwks8sc4@mail.elegosoft.com> As a first step, I've added p204 to the regression tests in m3tests which contains this program: MODULE Main; IMPORT IO, IP; CONST null = IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {0,0,0,0}}; VAR addr: IP.Address; one := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {1,1,1,1}}; BEGIN addr := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {87,250,125,7}}; addr := null; addr := one; IO.Put("OK\n"); END Main. Initializers null and one work, only the one in the main body leads to code generation errors: "../src/Main.m3", line 1: 4 code generation errors 1 error encountered Any volunteers? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From darko at darko.org Thu Feb 14 01:10:18 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 11:10:18 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B2E62D.1E75.00D7.1@scires.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> Message-ID: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> I actually see some benefit to Jay's postings since they make us examine some of the differences between M3 and C and explain the benefits. These questions might be asked by any C programmer approaching the M3 language. It may be the point that Jay hasn't created and serious software in M3 and needs to be informed of the benefits. I've seen some good responses along these lines from members of the list. But Randy does have a valid point. M3 is is not just different to C, it's the antithesis of C. It's everything C isn't and the language designers went to great lengths to make it this way. It's why most of us use the language. I certainly wouldn't like to drive anyone away because they have a different point of view, but it may be a good idea to examine problems and solutions more closely and offer other solutions that 'why not do it like C'. In the case of printf, it is useful, when debugging especially, and I've created some code which takes a list of refany parameters and prints them out. It is a bit inefficient since any 'atomic' values such as integers need to be allocated but it also prints out all the fields of structures and arrays. But it is completely safe. If there were a need for a more efficient way to generated formatted strings, I'd write something else more efficient but also configurable since embedding fixed strings in your code is generally a a bad idea. On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > Jay: > > I don't want to be offensive, but quite frankly I'm tired of > continually reading your gripes about Modula-3 as a language and > your pining for C. > > This forum is for those people interested in advancing the state of > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > us who are M3 zealots for the most part probably would welcome any > move to divest CM3 of all underpinnings from the C world. > > Have you seriously studied the Modula-3 language and used it to > build production software? I think some of your comments suggest > that you are not a true Modula-3 programmer and that you still cling > to the C-way of doing things rather than embracing the Modula-3 way. > > Now, I do think that most people are interested in improving things > and no language is perfect, so any well-thought-out proposal for a > change to the language is welcome for consideration, But in this > mail list forum, I for one would appreciate less ranting about C and > more constructive Modula-3. > > Truly, I do not want to offend you. Maybe I'm just having a bad > day, but I encourage you to try and focus your posts to the > advancement of Modula-3. > > Regards, > Randy > > >>> Jay 2/12/2008 11:28 PM >>> > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. > > The debugging options seem really poor everywhere and esp. on NT386. > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full > source paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > > Other than printf'ing, I also end up getting a stack in cdb with no > symbols and then disasm in gdb to find what the functions were. That > works fine a few times, but I hope not to do it often. Somewhat > lucky I could even get a stack. Because, see, cdb is nice enough to > stop on access violations by default (such as the time/date code was > causing). gdb has a promising sounding feature, the ability to stop > on "signals", which I think an access violation would count as, oh, > but that feature isn't implemented, sorry. Ok, true, think about it > more and I can break on the toplevel exception handler in > cygwin1.dll, not sure that always works or not, it's an > implementation detail, but heck, when you are debugging, take > advantage of whatever you have. :) > > RTIO, is too verbose for me. > But darnit, I can't really have printf..puts is about the best I > could do.. > Oh, but no, since TEXT != char* even that isn't useful. > fread/fwrite maybe though. > > On a different hand (how many are there? :) ), have you looked in > m3core\src\unix? > There is just tons of dead stuff, stuff with comments about it > perhaps being wrong, "use with care". > It seemed to me maybe the point was to expose "all" of /usr/include. > Someone, other than me, sure seems to have gone overboard, like > someone using Ultrix and Linux 1.x, and then it copied around. > Heck, look at the mem* functions being commented out (and probably > using the incorrect type int) because Ultrix or somesuch didn't have > them. I uncommented them to fix a build. And notice that these > functions, again, like most of printf, are /extremely/ portable in > functionality and exact binary interface (yeah yeah, I've heard of > bcopy and bzero). > > What there was of Cstdio.i3 seemed very possibly wrong, at least on > many targets, and very doubtfully useful for anything, and I think > I've now shown unused. > > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop > rewriting them... > Or some other language, ok...not going to be solved in this forum. > To go the unpopular route (again), MS CLR/.NET among many other > things, attempts to solve this very problem. > One way to describe "interfaces" that "all" languages can > understand...at least for some subset of languages features.. > > Just as tedious btw, it is often more portable to wrap all the C > APIs in C, exposing a portable controled Modula-3 interface > independent of the precise header content. Like errno and my > get_stderr/out/in. > > - Jay > > > > To: hosking at cs.purdue.edu > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > This is also an excellent reason not to permit "interfaces" to C > > code inlined into MODULEs. > > > > Interfaces are the contract that the implementation has to live up > > to. Ok, so it happens that under operating system X on architecture > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > system, which either isn't built in C or where the function doesn't > > exist, it might be convenient to implement the interface in (gasp!) > > Modula-3! > > > > (I use this pattern as follows: on systems where Intel's Fortran > > compiler is available, compile from assembly (which was generated > > by ifort). On other systems, the code is implemented in Modula-3.) > > > > Mika > > > > Tony Hosking writes: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > >What happens when I want to bring up a system where there is no > > >C?!?! Consider the SPIN OS perhaps... > > > > > >Maybe I am just being overly fusty... > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > >> What we _maybe_ can do... is to make some special, preprocessable > > >> source > > >> form, which some quake command can parse into multiple files in > their > > >> folders. And these file can be compiled later...Kind of how > generic > > >> works. > > >> > > >> But, as current system works, and it does it very well, and as > only > > >> case > > >> where we really need this is Windows... most Unices being or > becoming > > >> POSIX... I don't see it's smart to spend resources on becoming > more > > >> C... > > >> Esp when "founding fathers" made it so good and so much non-C :). > > >> > > >> If we really need to make some approach to "their world", it's > much > > >> better to work on interoperability issues and thus cement our > > >> first-class-citizen language status even more. > > >> > > >> dd > > >> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > >>> Jay: > > >>> > > >>> My understanding of Modula-3 is that rather than cluttering up > the > > >>> source code with a bunch of preprocessor directives to deal > with the > > >>> various changes needed by various platforms, a separate source > > >>> file is > > >>> used for platforms whose implementation must diverge. The > m3makefile > > >>> is used to control the selection of these platform sources at > build > > >>> time. I like this approach much better. > > >>> > > >>> Regards, > > >>> Randy > > >>> > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > >>> So I have NOT thought this through. > > >>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good > > >>> idea. > > >>> > > >>> Something like either the ability to prefix pragmas with a > target, or > > >>> an "iftarget" and "ifnottarget" pragma. > > >>> > > >>> Something like so: > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> It's a small can of worms. > > >>> Where can they be placed? Only at "global" scope? (ie: > toplevel in an > > >>> interface/module). > > >>> > > >>> What about IF_OSTYPE? > > >>> What about expressions? > > >>> IF_TARGET NT386 OR NTAMD64 > > >>> > > >>> IF_TARGET STARTS(NT) > > >>> > > >>> etc. > > >>> > > >>> I don't really have enough interest here to work through this, > just > > >>> sending out the bait... > > >>> > > >>> Obviously this was triggered by my happening into the odbc > directory > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > calling > > >>> conventions with a target. > > >>> > > >>> This reminds me of an important point here however -- nobody > else is > > >>> going to make the mistake of ever having multiple calling > > >>> conventions. > > >>> Therefore the generality of prefixing WINAPI with NT386: is > useless. > > >>> Unless Mac68K support is added. > > >>> > > >>> And here is some rationale even. The PC and Mac evolved from > "small" > > >>> systems, where assembly programming was common, more people > knew more > > >>> lower level details and playing games with calling conventions > was > > >>> something anyone could do. Most other current systems are > rooted in C > > >>> programming. Working in C, calling conventions are generally > in a > > >>> hidden layer below what anyone thinks about. Therefore, the > smaller > > >>> number of capable people working at that level have the good > sense to > > >>> only have one calling convention. No more systems will evolve > from > > >>> "small", at least not without having observed this history. > > >>> Therefore, > > >>> there will no longer be multiple calling conventions. > > >>> > > >>> That is my theory at least. > > >>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > __thiscall is > > >>> only x86 > > >> -- > > >> Dragi??a Duri?? > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Thu Feb 14 01:34:44 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 00:34:44 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: I'll try to repeat myself less and ramble less, and stay constructive... I understand that printf type unsafety stinks and I have been bitten by it, but it is nicely terse, crude but effective, I'm going to throw away the code probably once the bug is fixed. (Ok, I like to comment out or somehow disable sometimes maybe but that is a different point, it's still not the height of production code; and yes, I realize it's a slippery slope and the next thing I'll do is use it in production code; debugging is just what I'm doing now, next up, real code). You can't just be the antithesis of C. You have to decide what it is about C that is wrong and fix it or do it over. And then of course, agreement on what is wrong. I probably see less wrong than you. Bad module system -- #include. Bad module system -- preprocesor which kills or damages other efforts at language-aware tools. Beyond this, at the moment, I am unsure. I have "argued for" C++ for further "problems" in C, but I have "grown" (or shrunk? :) ) to appreciate that C might not be as bad as I used to think. If you start over completely from scratch, you should still look at what is out there. Granted, some things are mostly arbitrary. Braces vs. begin/end. But the editors all support braces now. Until you get me to change editors (probably never), Modula-3 is always going to be less convenient. At this point you are just fighting the vast majority (except Python...). It could have gone differently, but C won. If you ignore that lowest level thing, there are places where Modula-3 is perfectly good, but doesn't take the next step. A good example I think here is it has nice "objects", however it requires they be heap allocated I think even in unsafe code. You should be able stack (or global) allocate something with "virtual functions". It seems an arbitrary limitation. I realize in safe code, you have to heap allocate more anyway, but that is a different point I think. Similarly is "multiple inheritance just of interfaces". I realize though..this hides a "vtable per interface". Maybe is much more expensive than people realize and shouldn't be provided lightly. SUBARRAY is probably example where I don't/didn't know the language well enough. And maybe the docs aren't good here. And VAR/BEGIN. Maybe I just need to reread Nelson's book. You know..reference vs. tutorial. The language reference is very very terse and that is ok. Short on examples. A tutorial that gives many examples might be good. Hey maybe I'm just the newbie in a good position to write it. (not) I guess I should be in comp.lang.c.advocacy. :) To a large extent I'm just looking for a small smart group to have a friendly intellectual discussion with. (and of course, don't mess up their code) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay's postings since they make us > examine some of the differences between M3 and C and explain the > benefits. These questions might be asked by any C programmer > approaching the M3 language. It may be the point that Jay hasn't > created and serious software in M3 and needs to be informed of the > benefits. I've seen some good responses along these lines from members > of the list.> > But Randy does have a valid point. M3 is is not just different to C, > it's the antithesis of C. It's everything C isn't and the language > designers went to great lengths to make it this way. It's why most of > us use the language.> > I certainly wouldn't like to drive anyone away because they have a > different point of view, but it may be a good idea to examine problems > and solutions more closely and offer other solutions that 'why not do > it like C'.> > In the case of printf, it is useful, when debugging especially, and > I've created some code which takes a list of refany parameters and > prints them out. It is a bit inefficient since any 'atomic' values > such as integers need to be allocated but it also prints out all the > fields of structures and arrays. But it is completely safe. If there > were a need for a more efficient way to generated formatted strings, > I'd write something else more efficient but also configurable since > embedding fixed strings in your code is generally a a bad idea.> > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be offensive, but quite frankly I'm tired of > > continually reading your gripes about Modula-3 as a language and > > your pining for C.> >> > This forum is for those people interested in advancing the state of > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealots for the most part probably would welcome any > > move to divest CM3 of all underpinnings from the C world.> >> > Have you seriously studied the Modula-3 language and used it to > > build production software? I think some of your comments suggest > > that you are not a true Modula-3 programmer and that you still cling > > to the C-way of doing things rather than embracing the Modula-3 way.> >> > Now, I do think that most people are interested in improving things > > and no language is perfect, so any well-thought-out proposal for a > > change to the language is welcome for consideration, But in this > > mail list forum, I for one would appreciate less ranting about C and > > more constructive Modula-3.> >> > Truly, I do not want to offend you. Maybe I'm just having a bad > > day, but I encourage you to try and focus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy> >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> >> > This is somewhat my point.> > When I am debugging, I really miss printf.> >> > The debugging options seem really poor everywhere and esp. on NT386.> >> > gdb has all wierded out variable names for one thing.> > And I think we should fix it so that that the symbols have full > > source paths.> > I realize they would only be correct on one machine, and hopefully > > there's a decent story for copying the files.> > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot.> >> > Other than printf'ing, I also end up getting a stack in cdb with no > > symbols and then disasm in gdb to find what the functions were. That > > works fine a few times, but I hope not to do it often. Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enough to > > stop on access violations by default (such as the time/date code was > > causing). gdb has a promising sounding feature, the ability to stop > > on "signals", which I think an access violation would count as, oh, > > but that feature isn't implemented, sorry. Ok, true, think about it > > more and I can break on the toplevel exception handler in > > cygwin1.dll, not sure that always works or not, it's an > > implementation detail, but heck, when you are debugging, take > > advantage of whatever you have. :)> >> > RTIO, is too verbose for me.> > But darnit, I can't really have printf..puts is about the best I > > could do..> > Oh, but no, since TEXT != char* even that isn't useful.> > fread/fwrite maybe though.> >> > On a different hand (how many are there? :) ), have you looked in > > m3core\src\unix?> > There is just tons of dead stuff, stuff with comments about it > > perhaps being wrong, "use with care".> > It seemed to me maybe the point was to expose "all" of /usr/include.> > Someone, other than me, sure seems to have gone overboard, like > > someone using Ultrix and Linux 1.x, and then it copied around.> > Heck, look at the mem* functions being commented out (and probably > > using the incorrect type int) because Ultrix or somesuch didn't have > > them. I uncommented them to fix a build. And notice that these > > functions, again, like most of printf, are /extremely/ portable in > > functionality and exact binary interface (yeah yeah, I've heard of > > bcopy and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, at least on > > many targets, and very doubtfully useful for anything, and I think > > I've now shown unused.> >> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> >> > But wrapping everything in Modula-3 is so tedious...> > Oh for all languages to just understand C headers so we can stop > > rewriting them...> > Or some other language, ok...not going to be solved in this forum.> > To go the unpopular route (again), MS CLR/.NET among many other > > things, attempts to solve this very problem.> > One way to describe "interfaces" that "all" languages can > > understand...at least for some subset of languages features..> >> > Just as tedious btw, it is often more portable to wrap all the C > > APIs in C, exposing a portable controled Modula-3 interface > > independent of the precise header content. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: hosking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] "target specific pragmas"?> > >> > >> > > This is also an excellent reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >> > > Interfaces are the contract that the implementation has to live up> > > to. Ok, so it happens that under operating system X on architecture> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> > > system, which either isn't built in C or where the function doesn't> > > exist, it might be convenient to implement the interface in (gasp!)> > > Modula-3!> > >> > > (I use this pattern as follows: on systems where Intel's Fortran> > > compiler is available, compile from assembly (which was generated> > > by ifort). On other systems, the code is implemented in Modula-3.)> > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> > > >What happens when I want to bring up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps...> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> > > >> > > >> What we _maybe_ can do... is to make some special, preprocessable> > > >> source> > > >> form, which some quake command can parse into multiple files in > > their> > > >> folders. And these file can be compiled later...Kind of how > > generic> > > >> works.> > > >>> > > >> But, as current system works, and it does it very well, and as > > only> > > >> case> > > >> where we really need this is Windows... most Unices being or > > becoming> > > >> POSIX... I don't see it's smart to spend resources on becoming > > more> > > >> C...> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > > >>> > > >> If we really need to make some approach to "their world", it's > > much> > > >> better to work on interoperability issues and thus cement our> > > >> first-class-citizen language status even more.> > > >>> > > >> dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rather than cluttering up > > the> > > >>> source code with a bunch of preprocessor directives to deal > > with the> > > >>> various changes needed by various platforms, a separate source> > > >>> file is> > > >>> used for platforms whose implementation must diverge. The > > m3makefile> > > >>> is used to control the selection of these platform sources at > > build> > > >>> time. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> Randy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> > > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>> > > >>> Something like either the ability to prefix pragmas with a > > target, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>> Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interface/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about expressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET STARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enough interest here to work through this, > > just> > > >>> sending out the bait...> > > >>>> > > >>> Obviously this was triggered by my happening into the odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > > >>> This reminds me of an important point here however -- nobody > > else is> > > >>> going to make the mistake of ever having multiple calling> > > >>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> > > >>> And here is some rationale even. The PC and Mac evolved from > > "small"> > > >>> systems, where assembly programming was common, more people > > knew more> > > >>> lower level details and playing games with calling conventions > > was> > > >>> something anyone could do. Most other current systems are > > rooted in C> > > >>> programming. Working in C, calling conventions are generally > > in a> > > >>> hidden layer below what anyone thinks about. Therefore, the > > smaller> > > >>> number of capable people working at that level have the good > > sense to> > > >>> only have one calling convention. No more systems will evolve > > from> > > >>> "small", at least not without having observed this history.> > > >>> Therefore,> > > >>> there will no longer be multiple calling conventions.> > > >>>> > > >>> That is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> Dragi??a Duri?? > >> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Thu Feb 14 02:09:40 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 12:09:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> M3 is the antithesis in the sense that it takes the opposite approach. C has few protections, M3 has many. M3 does examine what was wrong with C and other languages and fix them and it did a good job. The M3 design team made an explicit goal to look at features from other languages and take the best. The fact that M3 works so well is the proof. Some of the things you raise, like braces or stack allocations of objects are just features of C++ with no justification. Can you show that typing less characters is important? You say M3 is less convenient, but what is less convenient, less typing or less bugs? Do you spend most of your time typing or thinking when you write code? Should language include every feature anyone can think of? How is excluding unimportant features 'arbitrary'? Each feature must be weighed to avoid unnecessary complexity and size, which have a direct impact on compiler maintainability and language usability. Language bloat is a real problem. I doubt that anyone understands the full semantics of C++. You say that C has 'won', but in what sense? More people use it? Language design is not American Idol, it's not a question of who has the most votes. You have to do more than list features of C or C++ and your opinions on them. You have to provide some rationale as to their benefit which convinces people. On 14/02/2008, at 11:34 AM, Jay wrote: > I'll try to repeat myself less and ramble less, and stay > constructive... > > I understand that printf type unsafety stinks and I have been bitten > by it, but it is nicely terse, crude but effective, I'm going to > throw away the code probably once the bug is fixed. (Ok, I like to > comment out or somehow disable sometimes maybe but that is a > different point, it's still not the height of production code; and > yes, I realize it's a slippery slope and the next thing I'll do is > use it in production code; debugging is just what I'm doing now, > next up, real code). > > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. > > If you start over completely from scratch, you should still look at > what is out there. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. > > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. > > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. > > SUBARRAY is probably example where I don't/didn't know the language > well enough. > And maybe the docs aren't good here. > And VAR/BEGIN. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) > > I guess I should be in comp.lang.c.advocacy. :) > > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) > > - Jay > > > > > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > > From: darko at darko.org > > To: rcoleburn at scires.com > > Subject: Re: [M3devel] "target specific pragmas"? > > Date: Thu, 14 Feb 2008 11:10:18 +1100 > > > > I actually see some benefit to Jay's postings since they make us > > examine some of the differences between M3 and C and explain the > > benefits. These questions might be asked by any C programmer > > approaching the M3 language. It may be the point that Jay hasn't > > created and serious software in M3 and needs to be informed of the > > benefits. I've seen some good responses along these lines from > members > > of the list. > > > > But Randy does have a valid point. M3 is is not just different to C, > > it's the antithesis of C. It's everything C isn't and the language > > designers went to great lengths to make it this way. It's why most > of > > us use the language. > > > > I certainly wouldn't like to drive anyone away because they have a > > different point of view, but it may be a good idea to examine > problems > > and solutions more closely and offer other solutions that 'why not > do > > it like C'. > > > > In the case of printf, it is useful, when debugging especially, and > > I've created some code which takes a list of refany parameters and > > prints them out. It is a bit inefficient since any 'atomic' values > > such as integers need to be allocated but it also prints out all the > > fields of structures and arrays. But it is completely safe. If there > > were a need for a more efficient way to generated formatted strings, > > I'd write something else more efficient but also configurable since > > embedding fixed strings in your code is generally a a bad idea. > > > > > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > > > > > Jay: > > > > > > I don't want to be offensive, but quite frankly I'm tired of > > > continually reading your gripes about Modula-3 as a language and > > > your pining for C. > > > > > > This forum is for those people interested in advancing the state > of > > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > > us who are M3 zealots for the most part probably would welcome any > > > move to divest CM3 of all underpinnings from the C world. > > > > > > Have you seriously studied the Modula-3 language and used it to > > > build production software? I think some of your comments suggest > > > that you are not a true Modula-3 programmer and that you still > cling > > > to the C-way of doing things rather than embracing the Modula-3 > way. > > > > > > Now, I do think that most people are interested in improving > things > > > and no language is perfect, so any well-thought-out proposal for a > > > change to the language is welcome for consideration, But in this > > > mail list forum, I for one would appreciate less ranting about C > and > > > more constructive Modula-3. > > > > > > Truly, I do not want to offend you. Maybe I'm just having a bad > > > day, but I encourage you to try and focus your posts to the > > > advancement of Modula-3. > > > > > > Regards, > > > Randy > > > > > > >>> Jay 2/12/2008 11:28 PM >>> > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > > > This is somewhat my point. > > > When I am debugging, I really miss printf. > > > > > > The debugging options seem really poor everywhere and esp. on > NT386. > > > > > > gdb has all wierded out variable names for one thing. > > > And I think we should fix it so that that the symbols have full > > > source paths. > > > I realize they would only be correct on one machine, and hopefully > > > there's a decent story for copying the files. > > > Yeah, I know about "dir" but haven't yet formed a .gdbinit or > whatnot. > > > > > > Other than printf'ing, I also end up getting a stack in cdb with > no > > > symbols and then disasm in gdb to find what the functions were. > That > > > works fine a few times, but I hope not to do it often. Somewhat > > > lucky I could even get a stack. Because, see, cdb is nice enough > to > > > stop on access violations by default (such as the time/date code > was > > > causing). gdb has a promising sounding feature, the ability to > stop > > > on "signals", which I think an access violation would count as, > oh, > > > but that feature isn't implemented, sorry. Ok, true, think about > it > > > more and I can break on the toplevel exception handler in > > > cygwin1.dll, not sure that always works or not, it's an > > > implementation detail, but heck, when you are debugging, take > > > advantage of whatever you have. :) > > > > > > RTIO, is too verbose for me. > > > But darnit, I can't really have printf..puts is about the best I > > > could do.. > > > Oh, but no, since TEXT != char* even that isn't useful. > > > fread/fwrite maybe though. > > > > > > On a different hand (how many are there? :) ), have you looked in > > > m3core\src\unix? > > > There is just tons of dead stuff, stuff with comments about it > > > perhaps being wrong, "use with care". > > > It seemed to me maybe the point was to expose "all" of /usr/ > include. > > > Someone, other than me, sure seems to have gone overboard, like > > > someone using Ultrix and Linux 1.x, and then it copied around. > > > Heck, look at the mem* functions being commented out (and probably > > > using the incorrect type int) because Ultrix or somesuch didn't > have > > > them. I uncommented them to fix a build. And notice that these > > > functions, again, like most of printf, are /extremely/ portable in > > > functionality and exact binary interface (yeah yeah, I've heard of > > > bcopy and bzero). > > > > > > What there was of Cstdio.i3 seemed very possibly wrong, at least > on > > > many targets, and very doubtfully useful for anything, and I think > > > I've now shown unused. > > > > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > > > But wrapping everything in Modula-3 is so tedious... > > > Oh for all languages to just understand C headers so we can stop > > > rewriting them... > > > Or some other language, ok...not going to be solved in this forum. > > > To go the unpopular route (again), MS CLR/.NET among many other > > > things, attempts to solve this very problem. > > > One way to describe "interfaces" that "all" languages can > > > understand...at least for some subset of languages features.. > > > > > > Just as tedious btw, it is often more portable to wrap all the C > > > APIs in C, exposing a portable controled Modula-3 interface > > > independent of the precise header content. Like errno and my > > > get_stderr/out/in. > > > > > > - Jay > > > > > > > > > > To: hosking at cs.purdue.edu > > > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > > > From: mika at async.caltech.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > > > > > > > This is also an excellent reason not to permit "interfaces" to C > > > > code inlined into MODULEs. > > > > > > > > Interfaces are the contract that the implementation has to > live up > > > > to. Ok, so it happens that under operating system X on > architecture > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > system, which either isn't built in C or where the function > doesn't > > > > exist, it might be convenient to implement the interface in > (gasp!) > > > > Modula-3! > > > > > > > > (I use this pattern as follows: on systems where Intel's Fortran > > > > compiler is available, compile from assembly (which was > generated > > > > by ifort). On other systems, the code is implemented in > Modula-3.) > > > > > > > > Mika > > > > > > > > Tony Hosking writes: > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > >What happens when I want to bring up a system where there is no > > > > >C?!?! Consider the SPIN OS perhaps... > > > > > > > > > >Maybe I am just being overly fusty... > > > > > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > > > > > >> What we _maybe_ can do... is to make some special, > preprocessable > > > > >> source > > > > >> form, which some quake command can parse into multiple > files in > > > their > > > > >> folders. And these file can be compiled later...Kind of how > > > generic > > > > >> works. > > > > >> > > > > >> But, as current system works, and it does it very well, and > as > > > only > > > > >> case > > > > >> where we really need this is Windows... most Unices being or > > > becoming > > > > >> POSIX... I don't see it's smart to spend resources on > becoming > > > more > > > > >> C... > > > > >> Esp when "founding fathers" made it so good and so much non- > C :). > > > > >> > > > > >> If we really need to make some approach to "their world", > it's > > > much > > > > >> better to work on interoperability issues and thus cement our > > > > >> first-class-citizen language status even more. > > > > >> > > > > >> dd > > > > >> > > > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > > > >>> Jay: > > > > >>> > > > > >>> My understanding of Modula-3 is that rather than > cluttering up > > > the > > > > >>> source code with a bunch of preprocessor directives to deal > > > with the > > > > >>> various changes needed by various platforms, a separate > source > > > > >>> file is > > > > >>> used for platforms whose implementation must diverge. The > > > m3makefile > > > > >>> is used to control the selection of these platform sources > at > > > build > > > > >>> time. I like this approach much better. > > > > >>> > > > > >>> Regards, > > > > >>> Randy > > > > >>> > > > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > > > >>> So I have NOT thought this through. > > > > >>> > > > > >>> I wonder if "preprocessing" dependent only on "target" is > a good > > > > >>> idea. > > > > >>> > > > > >>> Something like either the ability to prefix pragmas with a > > > target, or > > > > >>> an "iftarget" and "ifnottarget" pragma. > > > > >>> > > > > >>> Something like so: > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> It's a small can of worms. > > > > >>> Where can they be placed? Only at "global" scope? (ie: > > > toplevel in an > > > > >>> interface/module). > > > > >>> > > > > >>> What about IF_OSTYPE? > > > > >>> What about expressions? > > > > >>> IF_TARGET NT386 OR NTAMD64 > > > > >>> > > > > >>> IF_TARGET STARTS(NT) > > > > >>> > > > > >>> etc. > > > > >>> > > > > >>> I don't really have enough interest here to work through > this, > > > just > > > > >>> sending out the bait... > > > > >>> > > > > >>> Obviously this was triggered by my happening into the odbc > > > directory > > > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > > calling > > > > >>> conventions with a target. > > > > >>> > > > > >>> This reminds me of an important point here however -- nobody > > > else is > > > > >>> going to make the mistake of ever having multiple calling > > > > >>> conventions. > > > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > > useless. > > > > >>> Unless Mac68K support is added. > > > > >>> > > > > >>> And here is some rationale even. The PC and Mac evolved from > > > "small" > > > > >>> systems, where assembly programming was common, more people > > > knew more > > > > >>> lower level details and playing games with calling > conventions > > > was > > > > >>> something anyone could do. Most other current systems are > > > rooted in C > > > > >>> programming. Working in C, calling conventions are generally > > > in a > > > > >>> hidden layer below what anyone thinks about. Therefore, the > > > smaller > > > > >>> number of capable people working at that level have the good > > > sense to > > > > >>> only have one calling convention. No more systems will > evolve > > > from > > > > >>> "small", at least not without having observed this history. > > > > >>> Therefore, > > > > >>> there will no longer be multiple calling conventions. > > > > >>> > > > > >>> That is my theory at least. > > > > >>> > > > > >>> Oh, Windows does also have __thiscall and __clrcall. > > > __thiscall is > > > > >>> only x86 > > > > >> -- > > > > >> Dragi??a Duri?? > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From mika at async.caltech.edu Thu Feb 14 02:43:13 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 17:43:13 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. A few things I know I like about M3, and don't exist in the C languages, are: * enumerated types that work well * integer subranges * arrays(!!) * arrays indexed by enumerations and subranges * absence of name mangling problems (I'm willing to accept Quake in return) * the ability to add code/declarations/types to ANY interface and not have it break a program. NO OTHER LANGUAGE (that I've heard of) HAS THIS PROPERTY. * a lot of other Java-ish properties, without being Java. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. Yes it's a lot easier to code M3 in emacs... modula3.el is a wonderful little thing to have. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. Not even C++ has virtual methods in stack-allocated objects does it? If there's a language that has a lot of arbitrary limitations in this area it's C++. It's kind of funny: if you know Modula-3, you start by wondering how C++ implements X, where X is a feature you would like but M3 lacks, and then you find that while C++ does indeed implement X', that is, X in a restricted sense, it does actually not implement X in the full generality you'd like. And for the same reasons that M3 doesn't touch it in the first place. Stack-allocated objects are an example of this. If you want stack-allocated data structures, use a RECORD and a PROCEDURE. That will give you almost exactly the same thing that a stack-allocated object gives you in C++! >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) Try Harbison's book? Or read a lot of the SRC code. Some of it is quite beautiful. About C++: do you *really* know C++? I was reading Stroustrup's book a while back and after reading four or five times "if you want to try this, ask an experienced colleague first" I gave up in disgust on trying to understand C++. There are so many odd little ways you can go wrong in C++. Sometimes assigning an object to a variable causes your program to break in mysterious and horrible ways, sometimes... C++ programmers also tend to underestimate how effective garbage collection is in simplifying things. This is different from saying "garbage collection helps you avoid memory management errors" (because you say "I am a competent C++ programmer, I never make memory management errors"). Garbage collection lets you structure your code in ways that simply is not possible if you have to worry about which part of it is going to allocate and which part is going to deallocate memory. The last and probably biggest advantage of M3 over C++ is that you can look at a program and immediately know what it means. And also know that it *can't* mean anything else. The programmer couldn't, even if he was maximally sadistic, have overloaded equals to mean not-equals, right shift to mean left shift, and left shift to mean increment. C++ lets you do this, and there are a large number of programmers out there who seemingly take advantage of every language feature they can get their hands on that lets them obscure their programs. I would summarize it as follows. Modula-3 and C++ let you compile almost exactly the same machine code. Apart from that, Modula-3 does it in a way that lets you write safe programs, and C++ does it in a way that lets you write obscure programs. Something that has become increasingly clear to me is that Modula-3 and C++ live in something of a desert. There are very few modern programming languages that are as "close to the machine" as these two. All the work that people do today (that gets any attention) is in things like Java (which is incredibly complicated, have you ever tried to compile HotSpot?) and Python (which is all right but incredibly inefficient). The more academic languages like ML and things like Self... well I won't even say anything about those. If you want a safe language that works with traditional compiler tools, Modula-3 is just about the only one out there. Finally, there is something about Randy's comment that's very true. Modula-3 is a "dead language". People that "still" use it are going to be fanatics about why they use it, rather than C or C++. If you are asked what programming language you use for development, and you answer "Modula-3" people will almost always look at you like you're crazy. We do indeed use it because it is very different from C and C++, or else we would have saved ourselves a LOT of trouble (I forget just how many existing C and C++ libraries and tools I have reimplemented just so I could stay in Modula-3) by just going with the crowd. Mika >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From mika at async.caltech.edu Thu Feb 14 03:00:46 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 18:00:46 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> I should point out that I am not trying to tell you that Modula-3 is better than C++ and you should immediately switch and stop talking about the wonderful features of C++. It's not and if you are competent enough to be coding in C++ and happy with it you should certainly not. A way to summarize what I said before is this. I do not consider myself a good programmer. Yet I sit in front of my computer trying to write software that plays with millions of dollars of other people's money. I simply do not trust myself to use a tool as sharp and unconstrained as C++. The constraints of enumerated types, subranges, typechecking at interfaces and runtime, bounds-checked arrays etc., let me sleep a bit better (but still not well). I am reminded of something my advisor's advisor once wrote, regarding the difficulty of producing large software systems: We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers. ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF CACM 15, 1972, #10, 859-866) Mika Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From wagner at elegosoft.com Thu Feb 14 09:12:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 14 Feb 2008 09:12:09 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Quoting Jay : > I'll try to repeat myself less and ramble less, and stay constructive... That would be great. It's really nice that there is much more discussion here since you joined and much more work on the Windows targets, but it would still even better if you could (a) be less sarcastic (which tends to annoy some others) and (b) think once again before hitting the send button. On some days there's even so much traffic here that I can only browse the headers (there are dozens of other mails I need to pay close attention to). > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. C is good for special kinds of system programming, with very experienced users and a code base that can still be controlled by a few minds. Large projects tend to stretch these bounds easily. For large projects taking place in a commercial environment with many teams and well-specified layers and interfaces, M3 is IMO much better suited than C (or C++, or even Java), though ironically it's not really used there (which is a pity). > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. I like C much better than C++; it's small and can be useful. C++ is way too large and complex and has never been exactly defined. When we used to program point of sale systems in the early 90s for a company here in Berlin, we had two large files of more than 1200 pages which was the upcoming C++ spec draft. Nobody has ever read even 1/10 of it. We tried about half a dozen compilers, each with nice features, but they were completely incompatible, and cost much efforts to keep code even syntactically accepted. > If you start over completely from scratch, you should still look at > what is out there. Well, we're not doing that here (starting from scratch). M3 is a well-defined and well working language, and the community here likes to use it. I'm not against language changes in general, but they need to be considered very well if we really want to improve the language. Addition of a portable 64 bit integer type for once was something that was needed, because hardware architectures and operating systems have changed. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. Any decent editor can be configured wrt. syntax highlighting and writing support (we even had that for the simple DOS editors we were using at the university together with Modula-2). Have you tried (X)Emacs? There's a really nice m3-mode for it, with highlighting and automatic completion of all language constructs. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. I'm not fighting anybody here ;-) > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. I'm not sure if that is really needed. > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. Multiple inheritance was left out of the language after long discussions because it was not really understood at that time. It may be that things have changed in this respect, but I still don't think it is. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) You can express quite a lot of unexpected things with the few language constructs. Often I'm still amazed at the ideas of other programmers when reading M3 code. > I guess I should be in comp.lang.c.advocacy. :) Yes, some of your comments would be better placed there :) > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) I think you can have that here. People are willing to discuss and think things over, but the pace may be somewhat slower than you'd like :-) (It's not as bad as with Tolkien's Ents, but still ... slow :) So, as others have noted, it's great that there is so much activity recently, but it would still be better if the discussions and comments were more focused on important language related content about M3. Nobody has accused you of malicious intentions, and you've always accepted objections and corrections by others as far as I remember. I think what is mostly needed is to slightly adapt your style of working and discussing things to become better accepted here. Don't speak out too rash, and don't commit lots of small changes too soon. Work things out and become more self-confident about the results of your work. I'm sure you can contribute many interesting things to M3. Olaf PS: Sorry if some of the above reads as if I'm your teacher ;-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 14 09:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 08:38:14 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> References: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." <200802140200.m1E20k5k062986@camembert.async.caltech.edu> Message-ID: too much to respond to right now... Yes C++ certainly allows virtual functions on stack allocated objects. class Foo{public: virtual void Bar();}; void F(){ Foo foo; foo.Bar();} works fine. You can take the address and pass it around, etc., just don't return it of course. You are right that a record with procedures might suffice.I've been using them in C lately: struct Foo_t;typedef struct Foo_t Foo_t;struct FooFunctions_t;typedef struct FooFunctions_t FooFunctions_t; struct FooFunctions_t{ // probably never any data here, it muddies the model, but maybe void (*DoSomething)(Foo_t*); void (*OrSomethingElse)(Foo_t*, size_t a, size_t b);}; struct Foo_t{ // probably never any data here, it muddies the model, but maybe const FooFunctions_t* Functions;}; // see winnt.h for exactly correct definition#define CONTAINING_RECORD(basepointer, derivedtype, basefield) ((derivedtype*) ((char*)basepointer) - (offsetof(derivedtype, basefield)))) struct Bar_t{ size_t BarData...; Foo_t Base;}; void Bar_DoSomething(Foo_t* Foo){ Bar* = CONTAINING_RECORD(Foo, Bar_t, Base) do something with Bar->BarData...} void Bar_OrSomethingElse(...) ... const FooFunctions ={ &Bar_DoSomething, &Bar_OrSomethingElse}; Foo_t* Bar_Create(){ Bar_t* Bar = (Bar_t*) calloc(1, sizeof(*Bar)); if (Bar == NULL) .... Bar->Functions = &FooFunctions; return &Bar->Base; } Foo_t* f = Bar_Create(); f->Functions->DoSomething(f); // ouch a double pointer deref, maybe code will cache the functions though CONTAINING_RECORD isn't really needed here -- Base can be at the start -- but this slightly generalized pattern supports more types of inheritance better. Presumably I can just clone this in about as much Modula-3. I'll have to try it out when I find an excuse for having "COM-like" interfaces. "I can have my C and a good module system too." :) It is a little tedious, but it keeps you off the slippery slope of C++. :) C++ has few stupid limits I can think of. One is that types (or constants) with internal linkage can't be template parameters. void F() { struct point { int a,b; }; std::vector points; // error special_debugging_class<"print me"> abc; // error } Maybe the last is fixed though. And they are both widely acknowledged to be dumb. Though I think they have an obvious rationale. (You all can guess?) True I haven't written much Modula-3. I do look around the tree some and I do see a lot gross duplication of code/effort. Yes Modula-3 enums and sets and their interaction with arrays is nice. It was actually cryptically terse to me at first but I figured it out. Optional bounds checking on arrays, good. C++ gives you what you generally need to implement sets and good arrays. C is soso. You know, the main thing you have to give up in C regarding user defined types is using those special operator characters on them. You must make explicit function calls. There is this real tension between building stuff into a language vs. building in enough facilities for people to put in libraries what they "thought" should be in the language. Same thing even goes for libraries themselves. Do you put more functionality "in" them, or provide the right composable pieces for people to build what they want. Exceptions (which nobody mentioned) are a mixed bag btw. It's not that hard really to get C correct, esp. with macros and goto (seriously!) but also not clearly worth it. Optional garbage collection maybe nice, again not so hard in C, and C++ gives you, in a sense, garbage collection and much much more along these lines via "RIAA". Also true that lots of languages don't compile to native code. The CLR does promise to be the last system to need this (at runtime or install time) and everyone else can target it. Java (VM) is similar but not general purpose enough. True that name mangling is kind of lame. Try searching for the functions, or debugging (how do I specify the name to a command line debugger? It isn't necessarily impossible, but it's another varying complexity.) Also, on the "American Idol" point, true, good point, being right and good is better than being popular, but there are network affects and some of them are desirable. It's true you don't want everyone jumping on your bandwagon, you want to keep some folks out, but having other people writing tools (editors, etc.) that you can use CAN be very nice. True again I'm a lazy typist but a frequent reader. But begin/end are no more readable than braces. It seems arbitrary, except for the network affects that make my editor favor braces. ..Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Wed, 13 Feb 2008 18:00:46 -0800> From: mika at async.caltech.edu> > > I should point out that I am not trying to tell you that Modula-3> is better than C++ and you should immediately switch and stop talking> about the wonderful features of C++. It's not and if you are> competent enough to be coding in C++ and happy with it you should> certainly not.> > A way to summarize what I said before is this. I do not consider> myself a good programmer. Yet I sit in front of my computer trying> to write software that plays with millions of dollars of other> people's money. I simply do not trust myself to use a tool as sharp> and unconstrained as C++. The constraints of enumerated types,> subranges, typechecking at interfaces and runtime, bounds-checked> arrays etc., let me sleep a bit better (but still not well).> > I am reminded of something my advisor's advisor once wrote, regarding> the difficulty of producing large software systems:> > We shall do a much better programming job, provided that we> approach the task with a full appreciation of its tremendous> difficulty, provided that we stick to modest and elegant programming> languages, provided that we respect the intrinsic limitations> of the human mind and approach the task as Very Humble Programmers.> > ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF > CACM 15, 1972, #10, 859-866)> > Mika> > > > > > > Jay writes:> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I'll try to repeat myself less and ramble less, and stay constructive...> >=20> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).> >=20> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.> >Bad module system -- #include.> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.> >Beyond this, at the moment, I am unsure.> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.> >=20> >If you start over completely from scratch, you should still look at what is=> > out there.> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.> >=20> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.> >=20> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.> >=20> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.> > And maybe the docs aren't good here.> >And VAR/BEGIN.> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)> >=20> >I guess I should be in comp.lang.c.advocacy. :)> >=20> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.> >(and of course, don't mess up their code)> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To=> >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> => >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay=> >'s postings since they make us > examine some of the differences between M3=> > and C and explain the > benefits. These questions might be asked by any C => >programmer > approaching the M3 language. It may be the point that Jay hasn=> >'t > created and serious software in M3 and needs to be informed of the > b=> >enefits. I've seen some good responses along these lines from members > of => >the list.> > But Randy does have a valid point. M3 is is not just different=> > to C, > it's the antithesis of C. It's everything C isn't and the language=> > > designers went to great lengths to make it this way. It's why most of > => >us use the language.> > I certainly wouldn't like to drive anyone away beca=> >use they have a > different point of view, but it may be a good idea to exa=> >mine problems > and solutions more closely and offer other solutions that '=> >why not do > it like C'.> > In the case of printf, it is useful, when debug=> >ging especially, and > I've created some code which takes a list of refany => >parameters and > prints them out. It is a bit inefficient since any 'atomic=> >' values > such as integers need to be allocated but it also prints out all=> > the > fields of structures and arrays. But it is completely safe. If there=> > > were a need for a more efficient way to generated formatted strings, > I=> >'d write something else more efficient but also configurable since > embedd=> >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200=> >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off=> >ensive, but quite frankly I'm tired of > > continually reading your gripes => >about Modula-3 as a language and > > your pining for C.> >> > This forum is=> > for those people interested in advancing the state of > > Modula-3. We don=> >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot=> >s for the most part probably would welcome any > > move to divest CM3 of al=> >l underpinnings from the C world.> >> > Have you seriously studied the Modu=> >la-3 language and used it to > > build production software? I think some of=> > your comments suggest > > that you are not a true Modula-3 programmer and => >that you still cling > > to the C-way of doing things rather than embracing=> > the Modula-3 way.> >> > Now, I do think that most people are interested in=> > improving things > > and no language is perfect, so any well-thought-out p=> >roposal for a > > change to the language is welcome for consideration, But => >in this > > mail list forum, I for one would appreciate less ranting about => >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend => >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo=> >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>=> > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip=> >le concern is that once we provide C APIs then C will> > > >permeate the M3=> > space more pervasively (both apps and libraries).> >> > This is somewhat m=> >y point.> > When I am debugging, I really miss printf.> >> > The debugging => >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi=> >erded out variable names for one thing.> > And I think we should fix it so => >that that the symbols have full > > source paths.> > I realize they would o=> >nly be correct on one machine, and hopefully > > there's a decent story for=> > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g=> >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta=> >ck in cdb with no > > symbols and then disasm in gdb to find what the funct=> >ions were. That > > works fine a few times, but I hope not to do it often. => >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou=> >gh to > > stop on access violations by default (such as the time/date code => >was > > causing). gdb has a promising sounding feature, the ability to stop=> > > > on "signals", which I think an access violation would count as, oh, > => >> but that feature isn't implemented, sorry. Ok, true, think about it > > m=> >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n=> >ot sure that always works or not, it's an > > implementation detail, but he=> >ck, when you are debugging, take > > advantage of whatever you have. :)> >>=> > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..=> >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char=> >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen=> >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> => >> There is just tons of dead stuff, stuff with comments about it > > perhap=> >s being wrong, "use with care".> > It seemed to me maybe the point was to e=> >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have => >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co=> >pied around.> > Heck, look at the mem* functions being commented out (and p=> >robably > > using the incorrect type int) because Ultrix or somesuch didn't=> > have > > them. I uncommented them to fix a build. And notice that these > => >> functions, again, like most of printf, are /extremely/ portable in > > fu=> >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy => >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a=> >t least on > > many targets, and very doubtfully useful for anything, and I=> > think > > I've now shown unused.> >> > > Y, the easiest way to implement t=> >he interface is to call a C > > function> > > that "just happens" to have t=> >he correct interface. But on another> >> > But wrapping everything in Modul=> >a-3 is so tedious...> > Oh for all languages to just understand C headers s=> >o we can stop > > rewriting them...> > Or some other language, ok...not goi=> >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR=> >/.NET among many other > > things, attempts to solve this very problem.> > => >One way to describe "interfaces" that "all" languages can > > understand...=> >at least for some subset of languages features..> >> > Just as tedious btw,=> > it is often more portable to wrap all the C > > APIs in C, exposing a port=> >able controled Modula-3 interface > > independent of the precise header con=> >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h=> >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: => >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3=> >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent => >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >=> >> > > Interfaces are the contract that the implementation has to live up> >=> > > to. Ok, so it happens that under operating system X on architecture> > >=> > Y, the easiest way to implement the interface is to call a C > > function>=> > > > that "just happens" to have the correct interface. But on another> > >=> > system, which either isn't built in C or where the function doesn't> > > e=> >xist, it might be convenient to implement the interface in (gasp!)> > > Mod=> >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F=> >ortran> > > compiler is available, compile from assembly (which was generat=> >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>=> > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is=> > that once we provide C APIs then C will> > > >permeate the M3 space more p=> >ervasively (both apps and libraries).> > > >What happens when I want to bri=> >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..=> >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12=> >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma=> >ybe_ can do... is to make some special, preprocessable> > > >> source> > > => >>> form, which some quake command can parse into multiple files in > > thei=> >r> > > >> folders. And these file can be compiled later...Kind of how > > g=> >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it => >does it very well, and as > > only> > > >> case> > > >> where we really nee=> >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d=> >on't see it's smart to spend resources on becoming > > more> > > >> C...> >=> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > => >> >>> > > >> If we really need to make some approach to "their world", it's=> > > > much> > > >> better to work on interoperability issues and thus cement=> > our> > > >> first-class-citizen language status even more.> > > >>> > > >>=> > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote=> >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath=> >er than cluttering up > > the> > > >>> source code with a bunch of preproce=> >ssor directives to deal > > with the> > > >>> various changes needed by var=> >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo=> >rms whose implementation must diverge. The > > m3makefile> > > >>> is used => >to control the selection of these platform sources at > > build> > > >>> ti=> >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R=> >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> => >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "=> >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>=> >> > > >>> Something like either the ability to prefix pragmas with a > > ta=> >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>=> > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END=> >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E=> >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they => >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa=> >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp=> >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S=> >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou=> >gh interest here to work through this, > > just> > > >>> sending out the ba=> >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t=> >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386=> > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >=> > >>> This reminds me of an important point here however -- nobody > > else => >is> > > >>> going to make the mistake of ever having multiple calling> > > => >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with=> > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> => >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s=> >mall"> > > >>> systems, where assembly programming was common, more people => >> > knew more> > > >>> lower level details and playing games with calling c=> >onventions > > was> > > >>> something anyone could do. Most other current s=> >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv=> >entions are generally > > in a> > > >>> hidden layer below what anyone thin=> >ks about. Therefore, the > > smaller> > > >>> number of capable people work=> >ing at that level have the good > > sense to> > > >>> only have one calling=> > convention. No more systems will evolve > > from> > > >>> "small", at leas=> >t not without having observed this history.> > > >>> Therefore,> > > >>> th=> >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That => >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc=> >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D=> >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w=> >ays with Windows Live. Get it now!>=20> >_________________________________________________________________> >Shed those extra pounds with MSN and The Biggest Loser!> >http://biggestloser.msn.com/=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I'll try to repeat myself less and rambl=> >e less, and stay constructive...
> > 
> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).
> > 
> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.
> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.
> >Bad module system -- #include.
> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.
> >Beyond this, at the moment, I am unsure.
> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<=> >BR>> > 
> >If you start over completely from scratch, you should still look at what is=> > out there.
> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.
> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.
> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.
> > 
> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.
> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.
> > 
> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.
> > 
> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.
> >  And maybe the docs aren't good here.
> >And VAR/BEGIN.
> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)
> > 
> >I guess I should be in comp.lang.c.advocacy. :)
> > 
> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.
> >(and of course, don't mess up their code)
> > 
> > - Jay


> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar=> >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar=> >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>=> >;
> I actually see some benefit to Jay's postings since they make us=> >
> examine some of the differences between M3 and C and explain the => >
> benefits. These questions might be asked by any C programmer
&=> >gt; approaching the M3 language. It may be the point that Jay hasn't
&g=> >t; created and serious software in M3 and needs to be informed of the
&=> >gt; benefits. I've seen some good responses along these lines from members => >
> of the list.
>
> But Randy does have a valid point. M=> >3 is is not just different to C,
> it's the antithesis of C. It's ev=> >erything C isn't and the language
> designers went to great lengths => >to make it this way. It's why most of
> us use the language.
>=> >
> I certainly wouldn't like to drive anyone away because they have => >a
> different point of view, but it may be a good idea to examine pr=> >oblems
> and solutions more closely and offer other solutions that '=> >why not do
> it like C'.
>
> In the case of printf, it => >is useful, when debugging especially, and
> I've created some code w=> >hich takes a list of refany parameters and
> prints them out. It is => >a bit inefficient since any 'atomic' values
> such as integers need => >to be allocated but it also prints out all the
> fields of structure=> >s and arrays. But it is completely safe. If there
> were a need for => >a more efficient way to generated formatted strings,
> I'd write som=> >ething else more efficient but also configurable since
> embedding f=> >ixed strings in your code is generally a a bad idea.
>
>
&=> >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > => >Jay:
> >
> > I don't want to be offensive, but quite fran=> >kly I'm tired of
> > continually reading your gripes about Modula=> >-3 as a language and
> > your pining for C.
> >
> => >> This forum is for those people interested in advancing the state of >R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those=> > of
> > us who are M3 zealots for the most part probably would we=> >lcome any
> > move to divest CM3 of all underpinnings from the C => >world.
> >
> > Have you seriously studied the Modula-3 la=> >nguage and used it to
> > build production software? I think some=> > of your comments suggest
> > that you are not a true Modula-3 pr=> >ogrammer and that you still cling
> > to the C-way of doing thing=> >s rather than embracing the Modula-3 way.
> >
> > Now, I => >do think that most people are interested in improving things
> > => >and no language is perfect, so any well-thought-out proposal for a
>=> > > change to the language is welcome for consideration, But in this
=> >> > mail list forum, I for one would appreciate less ranting about C => >and
> > more constructive Modula-3.
> >
> > Tru=> >ly, I do not want to offend you. Maybe I'm just having a bad
> > => >day, but I encourage you to try and focus your posts to the
> > a=> >dvancement of Modula-3.
> >
> > Regards,
> > Ran=> >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2=> >/12/2008 11:28 PM >>>
> > > >My principle concern i=> >s that once we provide C APIs then C will
> > > >permeate th=> >e M3 space more pervasively (both apps and libraries).
> >
>=> > > This is somewhat my point.
> > When I am debugging, I really=> > miss printf.
> >
> > The debugging options seem really p=> >oor everywhere and esp. on NT386.
> >
> > gdb has all wie=> >rded out variable names for one thing.
> > And I think we should f=> >ix it so that that the symbols have full
> > source paths.
>=> >; > I realize they would only be correct on one machine, and hopefully <=> >BR>> > there's a decent story for copying the files.
> > Yea=> >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>=> > >
> > Other than printf'ing, I also end up getting a stack in => >cdb with no
> > symbols and then disasm in gdb to find what the f=> >unctions were. That
> > works fine a few times, but I hope not to=> > do it often. Somewhat
> > lucky I could even get a stack. Becaus=> >e, see, cdb is nice enough to
> > stop on access violations by de=> >fault (such as the time/date code was
> > causing). gdb has a pro=> >mising sounding feature, the ability to stop
> > on "signals", wh=> >ich I think an access violation would count as, oh,
> > but that => >feature isn't implemented, sorry. Ok, true, think about it
> > mo=> >re and I can break on the toplevel exception handler in
> > cygwi=> >n1.dll, not sure that always works or not, it's an
> > implementa=> >tion detail, but heck, when you are debugging, take
> > advantage=> > of whatever you have. :)
> >
> > RTIO, is too verbose fo=> >r me.
> > But darnit, I can't really have printf..puts is about th=> >e best I
> > could do..
> > Oh, but no, since TEXT !=3D => >char* even that isn't useful.
> > fread/fwrite maybe though.
&g=> >t; >
> > On a different hand (how many are there? :) ), have yo=> >u looked in
> > m3core\src\unix?
> > There is just tons => >of dead stuff, stuff with comments about it
> > perhaps being wro=> >ng, "use with care".
> > It seemed to me maybe the point was to ex=> >pose "all" of /usr/include.
> > Someone, other than me, sure seems=> > to have gone overboard, like
> > someone using Ultrix and Linux => >1.x, and then it copied around.
> > Heck, look at the mem* functio=> >ns being commented out (and probably
> > using the incorrect type=> > int) because Ultrix or somesuch didn't have
> > them. I uncommen=> >ted them to fix a build. And notice that these
> > functions, aga=> >in, like most of printf, are /extremely/ portable in
> > function=> >ality and exact binary interface (yeah yeah, I've heard of
> > bc=> >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme=> >d very possibly wrong, at least on
> > many targets, and very dou=> >btfully useful for anything, and I think
> > I've now shown unuse=> >d.
> >
> > > Y, the easiest way to implement the inter=> >face is to call a C
> > function
> > > that "just hap=> >pens" to have the correct interface. But on another
> >
> &g=> >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for=> > all languages to just understand C headers so we can stop
> > re=> >writing them...
> > Or some other language, ok...not going to be s=> >olved in this forum.
> > To go the unpopular route (again), MS CLR=> >/.NET among many other
> > things, attempts to solve this very pr=> >oblem.
> > One way to describe "interfaces" that "all" languages c=> >an
> > understand...at least for some subset of languages feature=> >s..
> >
> > Just as tedious btw, it is often more portabl=> >e to wrap all the C
> > APIs in C, exposing a portable controled => >Modula-3 interface
> > independent of the precise header content.=> > Like errno and my
> > get_stderr/out/in.
> >
> &g=> >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.=> >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g=> >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com=> >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>=> >; > >
> > >
> > > This is also an excellent r=> >eason not to permit "interfaces" to C
> > > code inlined into M=> >ODULEs.
> > >
> > > Interfaces are the contract tha=> >t the implementation has to live up
> > > to. Ok, so it happens=> > that under operating system X on architecture
> > > Y, the eas=> >iest way to implement the interface is to call a C
> > function >R>> > > that "just happens" to have the correct interface. But on => >another
> > > system, which either isn't built in C or where th=> >e function doesn't
> > > exist, it might be convenient to imple=> >ment the interface in (gasp!)
> > > Modula-3!
> > >=> >
> > > (I use this pattern as follows: on systems where Intel's=> > Fortran
> > > compiler is available, compile from assembly (wh=> >ich was generated
> > > by ifort). On other systems, the code i=> >s implemented in Modula-3.)
> > >
> > > Mika
>=> >; > >
> > > Tony Hosking writes:
> > > >My=> > principle concern is that once we provide C APIs then C will
> > => >> >permeate the M3 space more pervasively (both apps and libraries).<=> >BR>> > > >What happens when I want to bring up a system where t=> >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&=> >gt; > > >
> > > >Maybe I am just being overly fusty=> >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P=> >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g=> >t;> What we _maybe_ can do... is to make some special, preprocessable >>> > > >> source
> > > >> form, which some=> > quake command can parse into multiple files in
> > their
>=> > > > >> folders. And these file can be compiled later...Kind of=> > how
> > generic
> > > >> works.
> > &=> >gt; >>
> > > >> But, as current system works, and i=> >t does it very well, and as
> > only
> > > >> c=> >ase
> > > >> where we really need this is Windows... most=> > Unices being or
> > becoming
> > > >> POSIX...=> > I don't see it's smart to spend resources on becoming
> > more >R>> > > >> C...
> > > >> Esp when "foundin=> >g fathers" made it so good and so much non-C :).
> > > >>=> >
> > > >> If we really need to make some approach to "the=> >ir world", it's
> > much
> > > >> better to wor=> >k on interoperability issues and thus cement our
> > > >>=> > first-class-citizen language status even more.
> > > >><=> >BR>> > > >> dd
> > > >>
> > > => >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &=> >gt; > >>> Jay:
> > > >>>
> > >=> > >>> My understanding of Modula-3 is that rather than cluttering u=> >p
> > the
> > > >>> source code with a bunch=> > of preprocessor directives to deal
> > with the
> > >=> >; >>> various changes needed by various platforms, a separate sour=> >ce
> > > >>> file is
> > > >>> us=> >ed for platforms whose implementation must diverge. The
> > m3mak=> >efile
> > > >>> is used to control the selection of th=> >ese platform sources at
> > build
> > > >>> => >time. I like this approach much better.
> > > >>>
&=> >gt; > > >>> Regards,
> > > >>> Randy >>> > > >>>
> > > >>>>>> Jay=> > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g=> >t; >>> So I have NOT thought this through.
> > > >&=> >gt;>
> > > >>> I wonder if "preprocessing" dependen=> >t only on "target" is a good
> > > >>> idea.
> &=> >gt; > >>>
> > > >>> Something like either => >the ability to prefix pragmas with a
> > target, or
> > => >> >>> an "iftarget" and "ifnottarget" pragma.
> > >=> > >>>
> > > >>> Something like so:
> >=> >; > >>>
> > > >>> <* IF_TARGET NT386 *&=> >gt;
> > > >>> <* END_IF_TARGET*>
> > &g=> >t; >>>
> > > >>>
> > > >>&g=> >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_=> >TARGET*>
> > > >>> It's a small can of worms.
&g=> >t; > > >>> Where can they be placed? Only at "global" scope?=> > (ie:
> > toplevel in an
> > > >>> interface=> >/module).
> > > >>>
> > > >>> Wha=> >t about IF_OSTYPE?
> > > >>> What about expressions? >R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > => >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g=> >t; > >>>
> > > >>> etc.
> > > => >>>>
> > > >>> I don't really have enough inte=> >rest here to work through this,
> > just
> > > >&g=> >t;> sending out the bait...
> > > >>>
> > => >> >>> Obviously this was triggered by my happening into the odb=> >c
> > directory
> > > >>> and bringing up ig=> >noring WINAPI on non-NT386 or prefixing
> > calling
> > => >> >>> conventions with a target.
> > > >>>=> >
> > > >>> This reminds me of an important point here => >however -- nobody
> > else is
> > > >>> goin=> >g to make the mistake of ever having multiple calling
> > > >=> >;>> conventions.
> > > >>> Therefore the general=> >ity of prefixing WINAPI with NT386: is
> > useless.
> > => >> >>> Unless Mac68K support is added.
> > > >>=> >;>
> > > >>> And here is some rationale even. The P=> >C and Mac evolved from
> > "small"
> > > >>>=> > systems, where assembly programming was common, more people
> > => >knew more
> > > >>> lower level details and playing ga=> >mes with calling conventions
> > was
> > > >>&g=> >t; something anyone could do. Most other current systems are
> > => >rooted in C
> > > >>> programming. Working in C, calli=> >ng conventions are generally
> > in a
> > > >>&=> >gt; hidden layer below what anyone thinks about. Therefore, the
> &g=> >t; smaller
> > > >>> number of capable people working => >at that level have the good
> > sense to
> > > >&g=> >t;> only have one calling convention. No more systems will evolve
&g=> >t; > from
> > > >>> "small", at least not without h=> >aving observed this history.
> > > >>> Therefore,
&=> >gt; > > >>> there will no longer be multiple calling convent=> >ions.
> > > >>>
> > > >>> That is=> > my theory at least.
> > > >>>
> > > >&=> >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > => >__thiscall is
> > > >>> only x86
> > > >=> >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.=> >org>
> >
> >
> > Connect and share in new way=> >s with Windows Live. Get it now!
>


Shed those ext=> >ra pounds with MSN and The Biggest Loser! >n.com/' target=3D'_new'>Learn more.> >=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 14 18:31:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 12:31:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Message-ID: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: [...many other good comments deleted...] > Multiple inheritance was left out of the language after long > discussions because it was not really understood at that time. > It may be that things have changed in this respect, but I still > don't think it is. Multiple inheritance is fine so long as it encodes only type, but *not* if it encodes representation as well. Witness single inheritance for classes in Java, versus multiple inheritance for interfaces in Java. That seems to be the general consensus these days. >> To a large extent I'm just looking for a small smart group to have >> a friendly intellectual discussion with. >> (and of course, don't mess up their code) > > I think you can have that here. People are willing to discuss and > think things over, but the pace may be somewhat slower than you'd > like :-) > (It's not as bad as with Tolkien's Ents, but still ... slow :) > So, as others have noted, it's great that there is so much activity > recently, but it would still be better if the discussions and comments > were more focused on important language related content about M3. > Nobody has accused you of malicious intentions, and you've always > accepted objections and corrections by others as far as I remember. > > I think what is mostly needed is to slightly adapt your style of > working and discussing things to become better accepted here. > Don't speak out too rash, and don't commit lots of small changes > too soon. Work things out and become more self-confident about > the results of your work. I'm sure you can contribute many interesting > things to M3. Indeed, Jay, we need your Windows energy -- M3 needs to play well on Windows if it is to serve its true purpose: a language that allows applications to be written easily that also run on a multitude of platforms (POSIX, Mach/Darwin/OS X, Windows, ...). Randy is very keen to have a *stable*, easily installed, reliable, version of CM3 running on Windows. I am not sure we have reached that goal yet, even as you have put some great work into achieving that goal. I would very much encourage you to focus your efforts on achieving that kind of stability/reliability/usability for Windows. > PS: Sorry if some of the above reads as if I'm your teacher ;-) We are all padawans Obi-wan. ;-) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Thu Feb 14 19:08:35 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:08:35 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <20080214180835.GA30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 04:28:41AM +0000, Jay wrote: > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop rewriting them... > Or some other language, ok...not going to be solved in this forum. As usual, the problem has no solutions, and there are programs that solve it. It can't be solved because a lot of C headers -- especially the standard ones -- use implementation-dependent, and often undocumented, code behind the scenes. This makes it essentially impossible to define what a "C header" is for purposes of implemetation. But it has been solved, for many practical purposes, byt a program that reads C header files and generates the interface code that's needed by other languages to interface with the C code. I'm not sure of that program's name but "swix" comes to mind. Can anyone confirm that? The program possiblyknown as swix has to be configured (in a configuration file) for the particular target language. And you'd best check the output -- it may not automagically handle *everything* C compilers can throw at it. But it is useful. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:34:27 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:34:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <20080214183427.GB30167@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: > M3 is the antithesis in the sense that it takes the opposite approach. > C has few protections, M3 has many. M3 does examine what was wrong > with C and other languages and fix them and it did a good job. The M3 > design team made an explicit goal to look at features from other > languages and take the best. The fact that M3 works so well is the > proof. > > Some of the things you raise, like braces I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and 'END'. Natural languages evolve in the direction of having the mopst-oftern used words be the shortest. This makes it possible to say muc in less space and time. And it makes it easier to get an overview of a program whose physical size is becoming inconvenient. Just haveing the code be readable and seeing enough of its context makes debugging easier. > or stack allocations of > objects are just features of C++ with no justification. Stack allocation of objects is not such a big issue in C++. But it can be a big issue in those programs where split-second real-time interaction is an issue. Yes, I know this is the traditional argument against garbage collection, and that it is usually based on FUD rather than reality. But I have recently been in close contact with a programmer of video games, and for some of them the fraction-of-a-second pauses are a real problem. He really *wants* to write his games in a decent language, and he knows that C is not one. But every time he avoids heap allocation he delays the pause. If he can delay it enough, it's a win. If he can delay it altogether, that's success. > Can you show > that typing less characters is important? You say M3 is less > convenient, but what is less convenient, less typing or less bugs? This is a false dichotomy. You may well be able to reduce typing *and* reduce bugs, just by making code more readable. I doubt that typing "PROC" instead of "PROCEDURE", for example, is likely to introdice bugs. Not typing '{' instead of "BEGIN". Using special characters and lower-case keywords is likely to reduce bugs, because it's less likely that one will be misread for another. > Do > you spend most of your time typing or thinking when you write code? I think before I write code. I don't stop thinking when I start writing code, and I like to record my thoughts as I think. The less typing I need to do, the better I can get visual feedback on my thoughts while thinking. Sometimes the typing gets so tedious I get bored and lose interest. Then extra typing causes extra bugs. > > Should language include every feature anyone can think of? No. > How is > excluding unimportant features 'arbitrary'? Each feature must be > weighed to avoid unnecessary complexity and size, which have a direct > impact on compiler maintainability and language usability. Language > bloat is a real problem. I doubt that anyone understands the full > semantics of C++. > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. Enough people use it that it has become a fixture in the programming world. If you want to reuse existing code instead of always writing new, you are pretty much forced into some kind of interfacing between C and a reasonable language. The convenience of this interfacing can well determine whether the reasonable language is feasible for a specific application. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:59:47 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:59:47 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Message-ID: <20080214185947.GC30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > Not even C++ has virtual methods in stack-allocated objects does > it? To my knowledge (as former C++ implementor), it does. But such a stack-allocated variable is of statically-known actual type, so the compiler can statically resolve all virtual methods to the actual function implementing them. And it you pass the address of such an object to another function, the other function will handle its virtual methods by the usual virtual function lookup. The only real problem is that it's a bloody disaster if you try to free one of them as if it has been dynamically allocated. But that wouldn't be a problem in a garbage-collected language. > If there's a language that has a lot of arbitrary limitations > in this area it's C++. It's kind of funny: if you know Modula-3, > you start by wondering how C++ implements X, where X is a feature > you would like but M3 lacks, and then you find that while C++ does > indeed implement X', that is, X in a restricted sense, it does > actually not implement X in the full generality you'd like. And > for the same reasons that M3 doesn't touch it in the first place. > Stack-allocated objects are an example of this. If you want > stack-allocated data structures, use a RECORD and a PROCEDURE. That > will give you almost exactly the same thing that a stack-allocated > object gives you in C++! Not quite -- you lose its ability to be considered an inheritor of another class. That's a big loss. > About C++: do you *really* know C++? I was reading Stroustrup's > book a while back and after reading four or five times "if you want > to try this, ask an experienced colleague first" I gave up in disgust > on trying to understand C++. As implementor, I suppose I might be considered an experienced colleague. > There are so many odd little ways you > can go wrong in C++. Yup. That's why I like to avoid using it. > Sometimes assigning an object to a variable > causes your program to break in mysterious and horrible ways, > sometimes... It should never have allowed those potentially type-violating assignments. > C++ programmers also tend to underestimate how effective > garbage collection is in simplifying things. This is different > from saying "garbage collection helps you avoid memory management > errors" (because you say "I am a competent C++ programmer, I never > make memory management errors"). Garbage collection lets you > structure your code in ways that simply is not possible if you have > to worry about which part of it is going to allocate and which part > is going to deallocate memory. There's code I wouldn't venture to write without built-in garbage collection. C++ throws a sop at the programmer in the form of enabling him to core reference-counting in an at least semi-automatic way, but it isn't enough. -- hendrik From rodney.bates at wichita.edu Thu Feb 14 23:56:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 16:56:13 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: <47B4C70D.4010408@wichita.edu> OK. So would my proposal 1) below suffice, that the alignment rules are a property of a type and thus the same for every variable of that type? More immediately relevant, is it true that nothing that uses LAZYALIGN rules is ever pickled? I believe current pickles will trash things badly if that happens. Fixing this without invalidating existing pickles and/or compiled code looks tricky. If nothing LAZYALIGN is pickled, I am hoping to be able to come up with a scheme that will fix pickles, not require rewriting of any already existing pickle files or recompilation of existing object code, and yet not introduce any new bugs involving old pickles/code. Maybe I should just postpone this one until after LONGINT in pickles is supported (only with STRICTALIGN, as now for other types.) Darko wrote: > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures. > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > >> It sounds like all that Mac OS X needs is for _all_ types in an entire >> program to use the liberal packing rules. Have I understood correctly? >> I would have no grief over that. >> >> Darko wrote: >> >>> The liberalised alignment rules are required for the native Mac OS >>> X API and should stay. You cannot use that API without them. I >>> think the pragma is not required and can be removed. I agree with >>> all the points you make. The effect of the modified alignment rules >>> it to allow *packed* structures to have members aligned on byte >>> boundaries. This has the effect of packing the fields in the >>> tightest arrangement allowed by the platform. This might affect >>> performance, but if the user is concerned about this they should >>> specify field bit sizes that deliver improved performance. I don't >>> see a need to specify this on a structure level, for the reasons >>> you give and because the difference isn't significant enough in the >>> case of packed structures and their physical layout and >>> restrictions are platform dependent anyway. >>> I might also add that the alignment code is currently broken on >>> I386_DARWIN. >>> - Darko >>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> >>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>> being used anywhere? >>>> >>>> It is not documented in pragmas.html. The compiler front end appears >>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>> limitations on what declarations the pragma can appear on, but these >>>> are not actually enforced.) It liberalizes the alignment rules, >>>> generally allowing scalars to start on any byte boundary. >>>> >>>> Pickles have to be able to reconstruct the layout of types as the >>>> compiler would have done it for a machine (on which a now-being-read >>>> pickle was written) with different word size and alignment properties. >>>> Currently, pickles are completely unaware of lazy alignment. It >>>> would have to be encoded in type descriptions generated by the >>>> compiler >>>> using TipeDesc and read by pickles using RTTipe. >>>> >>>> Most troubling to me is what looks like a linguistic Pandora's box. >>>> The pragma can be associated with any constant, variable, or type >>>> _declaration_ (not type definition), with the result that different >>>> values of the same type can actually be different in their alignment >>>> rules and thus their layout. Similarly for different identifiers >>>> equated to the same type. Although the effects of this could possibly >>>> be hidden from the programmer in purely safe code, not so with unsafe >>>> code. I haven't thoroughly thought this through, but seems to me to >>>> really fly in the face of the whole typing philosophy of the language. >>>> >>>> For example, if pickles were to read in an object value, and there >>>> were >1 variants of the object's type in the reading program, >>>> differing >>>> only in the alignment rules, how would it decide which one to build? >>>> In fact, ignoring pickles altogether and just looking at a single >>>> program, >>>> if the object's type doesn't actually uniquely give its memory layout, >>>> how can it be accessed correctly? >>>> >>>> Additionally, a quick look at the compiler suggests it won't generate >>>> correct code for whole record assignment when the LHS and RHS are the >>>> same type but have different alignment characteristics. >>>> >>>> The more I think about it, it seems the only workable >>>> possibilities are: >>>> >>>> 1) Require the pragma to be associated only with a type >>>> _definition_ not a >>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>>> this a >>>> property of the type that propagates to all names for the type and >>>> all variables, constants, etc. Also, this would make this property >>>> a part of the type signature that pickles uses when reading, -OR- >>>> >>>> 2) Forget it altogether. >>>> >>>> What do people think? >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 00:22:06 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:22:06 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <47B4CD1E.100@wichita.edu> Detecting use of uninitialized variables statically is undecidable, although a good many specific (and common) cases can be caught or ruled out. Detecting at runtime requires a spare bit pattern that normal values of the type don't use, or an extra bit or something--not too convenient for some types. I have always been a bit ambivalent about Modula-3's rule that every variable is initialized to some unspecified bit pattern that is a valid value of the type. I understand this is the minimum requirement to ensure type safety. But for the same price already paid to do this (runtime initialization code), we could have default initialization to a language-specified value, which would make for more consistent behavior. I have been gradually expanding the habit of writing an explicit initial value on just about everything, whether bug-free code would need it or not, just for the reduced risk of unreproduceable bugs. Of course, if the type's representation uses every bit pattern, then the rule we have has no cost, whereas a language-specified initial value would. Jay wrote: ... > Java and I presume C# have a nice feature here too where they require > the compiler to error for use of uninitialized variables, though I > suspect the specced algorithm misses some things, like: > > if (...) > initialize x > > common code > > if (same thing) > use x <== possible use of uninitialize x, not > > At least I've seen other tools (not Java/C# compilers, I don't use > those) get confused by this.. >-- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 15 00:05:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:05:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: I don't want to add fuel to the fire, but .... On Feb 14, 2008, at 1:34 PM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. There are true "real-time" garbage collectors in development and deployment now that avoid applications from seeing pauses. Modula-3 is getting better in this respect, but it is still not quite there. But, fortunately, Modula-3 provides UNTRACED objects/ references which *never* themselves cause GC. In fact, for the current CM3 implementation it would be possible to have a real-time thread run and manipulate only UNTRACED references and never ever see a GC pause -- it would keep running even while other threads are caught up by GC! >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. I don't find M3 to be unreadable at all. In fact, I find it to be very readable. > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. Who types? I use an editor that completes and indents Modula-3 code with exactly the same number of keystrokes as I use when programming in C. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. And CM3 does this very well -- that does not mean we should permeate the Modula-3 space with C'isms. > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 00:06:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:06:48 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214185947.GC30167@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> Message-ID: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> PS The C++ standard committee is actively developing the next C++ standard to include garbage collection as part of the spec. The worm has turned... On Feb 14, 2008, at 1:59 PM, hendrik at topoi.pooq.com wrote: > On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > >> Not even C++ has virtual methods in stack-allocated objects does >> it? > > To my knowledge (as former C++ implementor), it does. But such a > stack-allocated variable is of statically-known actual type, so the > compiler can statically resolve all virtual methods to the actual > function implementing them. And it you pass the address of such an > object to another function, the other function will handle its virtual > methods by the usual virtual function lookup. > > The only real problem is that it's a bloody disaster if you try to > free one of them as if it has been dynamically allocated. But that > wouldn't be a problem in a garbage-collected language. > >> If there's a language that has a lot of arbitrary limitations >> in this area it's C++. It's kind of funny: if you know Modula-3, >> you start by wondering how C++ implements X, where X is a feature >> you would like but M3 lacks, and then you find that while C++ does >> indeed implement X', that is, X in a restricted sense, it does >> actually not implement X in the full generality you'd like. And >> for the same reasons that M3 doesn't touch it in the first place. >> Stack-allocated objects are an example of this. If you want >> stack-allocated data structures, use a RECORD and a PROCEDURE. That >> will give you almost exactly the same thing that a stack-allocated >> object gives you in C++! > > Not quite -- you lose its ability to be considered an inheritor of > another class. That's a big loss. > >> About C++: do you *really* know C++? I was reading Stroustrup's >> book a while back and after reading four or five times "if you want >> to try this, ask an experienced colleague first" I gave up in disgust >> on trying to understand C++. > > As implementor, I suppose I might be considered an experienced > colleague. > >> There are so many odd little ways you >> can go wrong in C++. > > Yup. That's why I like to avoid using it. > >> Sometimes assigning an object to a variable >> causes your program to break in mysterious and horrible ways, >> sometimes... > > It should never have allowed those potentially type-violating > assignments. > >> C++ programmers also tend to underestimate how effective >> garbage collection is in simplifying things. This is different >> from saying "garbage collection helps you avoid memory management >> errors" (because you say "I am a competent C++ programmer, I never >> make memory management errors"). Garbage collection lets you >> structure your code in ways that simply is not possible if you have >> to worry about which part of it is going to allocate and which part >> is going to deallocate memory. > > There's code I wouldn't venture to write without built-in garbage > collection. C++ throws a sop at the programmer in the form of > enabling > him to core reference-counting in an at least semi-automatic way, > but it > isn't enough. > > -- hendrik From rodney.bates at wichita.edu Fri Feb 15 00:32:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:32:57 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <47B4CFA9.2060400@wichita.edu> Whether you agree with their conclusions or not, the designers of Modula-3 and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing just that. Despite having a few complaints and ambivalences here and there, I for one, think the final result is unmatched for the ways it made all the very difficult tradeoffs among highly contradictory desiderata. Jay wrote: .... > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. .... > If you start over completely from scratch, you should still look at what > is out there. -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 15 00:18:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:18:32 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> Why is LONGINT for pickles not yet supported? On Feb 14, 2008, at 5:56 PM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment > rules are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any > already existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in > pickles is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible >> with C and Unix interfaces. The alignment change was implemented >> to be supported only in packed structures as a natural and >> intuitive way to "force" alignment. You could view it as a bug >> fix to overly restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without >>>> them. I think the pragma is not required and can be removed. I >>>> agree with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have >>>> members aligned on byte boundaries. This has the effect of >>>> packing the fields in the tightest arrangement allowed by the >>>> platform. This might affect performance, but if the user is >>>> concerned about this they should specify field bit sizes that >>>> deliver improved performance. I don't see a need to specify >>>> this on a structure level, for the reasons you give and >>>> because the difference isn't significant enough in the case of >>>> packed structures and their physical layout and restrictions >>>> are platform dependent anyway. >>>> I might also add that the alignment code is currently broken >>>> on I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by >>>>> the compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type >>>>> and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 darko at darko.org Fri Feb 15 00:26:23 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:26:23 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> The alignment rules are correctly associated with a type. I think the pragma can be removed. There are no pickles anywhere of these types. On 15/02/2008, at 9:56 AM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment rules > are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any already > existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in pickles > is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible with >> C and Unix interfaces. The alignment change was implemented to be >> supported only in packed structures as a natural and intuitive way >> to "force" alignment. You could view it as a bug fix to overly >> restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without them. >>>> I think the pragma is not required and can be removed. I agree >>>> with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have members >>>> aligned on byte boundaries. This has the effect of packing the >>>> fields in the tightest arrangement allowed by the platform. >>>> This might affect performance, but if the user is concerned >>>> about this they should specify field bit sizes that deliver >>>> improved performance. I don't see a need to specify this on a >>>> structure level, for the reasons you give and because the >>>> difference isn't significant enough in the case of packed >>>> structures and their physical layout and restrictions are >>>> platform dependent anyway. >>>> I might also add that the alignment code is currently broken on >>>> I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by the >>>>> compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 Fri Feb 15 00:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:31:03 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: > I don't want to add fuel to the fire, but .... > there. But, fortunately, Modula-3 provides UNTRACED objects/ > references which *never* themselves cause GC. In fact, for the Right, "optional safety" is a nice feature of Modula-3. C# has optional safety but I think maybe in fewer ways -- optional integer overflow checks, not sure what else. Otherwise optional safety seems to be pretty rare. This does remind us -- I don't think Modula-3's integer overflow rules are as obviously safe as they could be. I think it's a target-varying thing and most targets don't check. Integer overflow has started to become a concern like buffer overflow..so probably something should be done. HOWEVER something pervasive and automatic may be too risky in terms of compatibilty with existing code. I mean Modula-3. In C and C++, for "useful suggestions", there have been two obvious patterns: Functions to add, subtract, multiple integers, that can fail. Tedious but explicit. Probably good candidates for building into the language/compiler like Word, even if they are explicit functions. Templatized types with all the operators overloaded. Also a good candidate for inclusion in the language/compiler. What to call? There is "SafeInt". I think Modula-3 has more chance of getting away with just making it so for INTEGER but I would have to read up more. In C as I understand: The encoding and overflow behavior of signed integers is undefined/implemention-defined. You could have signed magnitude, one's complement, two's complement, or anything you want. You can have any behavior for integer overflow. Some sort of "wrap around", abort(), etc. For unsigned integers, overflow is well defined, never an error, and "wraps around". In practise, signed integers are always two's complement, overflow is never an error, and "wraps around", the same or nearly the same as unsigned integers. "Wrap around" being better defined as results are taken modulo 2^(bitsize(the type)). Signed and unsigned operations often generate identical code, but not always. For example add and subtract are often identical. Comparison can be identical and then use a different conditional branch. I'm just being lazy here, if I really dig into it I could remember/re-derive the rules, though I don't know the instructions sets. (on 6502, the compare instruction only works for unsigned, you have to subtract and destroy a register, of which there are only three, though another point of view considers memory, or certain memory, as registers, yes I know that sounds plain wrong, but when all you have is a,x,y and single byte addresses have more features (addressing modes) than larger addresses...). - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 00:35:52 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:35:52 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: > From: rodney.bates at wichita.edu> > Whether you agree with their conclusions or not, the designers of Modula-3> and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing The end of Nelson's book is VERY interesting in this regard, "How Modula-3 got its spots". I had previously never thought about type name vs. structural equivalence, or even knew to ask about them. - Noam :) _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Feb 15 00:47:01 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:47:01 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> I don't really question the usefulness of any given feature, just the incremental cost of adding any given feature. One of M3's great strengths is that it is low on features, but the ones it has are powerful and well chosen. The comparison I meant in the typing discussion was between C and M3, not the length of symbols. C is a bit obsessive about source size, which was meaningful back in the day, but today is totally irrelevant. Even if you don't use macros on your editor, the amount of time spent staring and your code is much greater than the time you spend typing it. You could argue that BEGIN/END is easier to read than {/} but I think the more important point is that this issue is not a significant one. On 15/02/2008, at 5:34 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. > > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. > > -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:18:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:18:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <20080215141819.GB3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} If I had to argue, I'd argue the reverse. In fact, if it weren't for disputes about the number of spaces that are equivalent to a tab and such, I'd argue for using indentation and dispensing with BEGIN/END/{/} altogether. Somewhere I have a C++ program with all the braces left out. If you manage to supply the right braces and get it compiled, you end up with a program that will do the job of supplying the right braces. I could post it here if anyone in interested in such a curiosity. There's one language I've seen that goes in the opposite direction. Every END is followed by an arbitrary amount of text from the start of the construct it closes and a semicolon. This a WHILE loop starting WHILE toronto == montreal could end with END WHILE toronto ==; making visual matchin unambiguous. I've got friends that complain about haveing to type the name if a procerure twice in its declaration -- once at the start and once at the end. They say they keep fprgetting to modify both. But I welcome this as a useful check on long-range bracket matching. Forcing it for short-range marching, though, is clutter. -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:20:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:20:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> Message-ID: <20080215142042.GC3639@topoi.pooq.com> On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: > PS The C++ standard committee is actively developing the next C++ > standard to include garbage collection as part of the spec. What are they ever going to do with those autodecremented pointers into the middle of arrays? -- hendrik From jayk123 at hotmail.com Fri Feb 15 16:10:16 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:10:16 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: Having written a bit of Python..really just a bit..you are all privy to ALL of the Python I have ever written...I'll bite. It's fairly obvious once you write a bit of Python what goes on here. First, we all know that we all strive to indent things "correctly". Now, "correctly" can vary somewhat, but the intent is universal. Deeper lexical nesting goes with increased indentation. You can pick the indent size, spaces vs. tabs, where the braces/begin/end go, but it's still the same intent. Now, when paired with begin/end or braces, you end up with a large duplication of information. The one the compiler uses only and the ones human use more. You get to keep them in sync. Your editor might help a lot. What Python does is merely throw out half the data, and require some consistency on your part for what in other languages the compiler ignores. I don't know the exact rules, but they are probably easy to think of. That is, it could easily allow either spaces or tabs. This approach is not bad. But I have two problems: 1) again, my editor 2) it's a little wierd and hard to see when you have a whole lot of closes in a row if print if print if print nothing here vs. either C or Modula-3. Perhaps a better approach is to require "end" and require consistent indentation. Python also can't cope with an empty statement because of this plus its lack of semicolons. You have to say "pass". That's a bit of an indictment. As to tabs, the answer is very easy. Never ever use them. Lots of folks use 4 space tabs, lots of folks use 8 space tabs. I used to be a 4 space tab guy, but I gave up tabs a few years ago. The Cygwin code uses 8 space tabs and is therefore unreadable to me. (I could change my editor setting, and since the 4 space tabs are pretty rare now, ok.) To those who suggested emacs for convenient Modula-3 editing, sorry, it's not likely going to happen. I have tried vi and emacs multiple times through the years and I can't use either. I use vi just for editing commit comments, which are often pasted in to the console from notepad anyway. My "problem" is that I make heavy use of the arrows, home, end, page up, page down, control, and shift. (control can "accelerate" arrows, shift is used for selecting). And some other ingrained keyboard short cuts like control-f, F3, etc. I use Visual C++ 5.0 and its support for these keys, plus a little bit of support for indentation, is excellent. It could be that the newer versions are better, and I would like find-and-REPLACE in files, and support for unicode files, but these aren't worth it so far. Oh, and the find-in-files, minus a replace option, is excellent, just super duper, I use it constantly. Nothing else compares. The only people I try to get to change editors is people that use notepad. On PPC_DARWIN I make do with TextWrangler. It is ok. (From the BBEdit folks). On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. If anyone out there is struggling with too-basic editors such as TextEdit or whatever it's called these days, I'd recommend trying these. But if you are already using a "programmer's editor", I'll leave you alone. :) If anyone knows of something more comparable to Visual C++ 5.0 on other platforms, I'm eager to hear. (Maybe under Wine? But that requires x86 I think..) Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), but it starts up slowly on Windows, crashes a bit on Windows, and isn't being updated.. (Trying for "gentle advise" not "advocacy" here.) > > incremental cost of adding any given feature. One of M3's great I think the problem is more of multiplication than increment. How do the features interact with each other? Two features interact very very well -- destructors and exceptions. And constructors in that mix. Otherwise not certain. > C is a bit obsessive about source size, There used to be an assembler that used tabs and a competitor that used spaces. The tab guy advertised his much smaller files. :) And I think therefore faster assembling. Well, definitely much faster assembling either way, probably not because of or only because of the tabs. Yes I have that problem with procedures. And modules, and interfaces. This is where my editor and braces excel. You need to sprinkle in the matching text. You type control-brace on a brace and it shows you the matching one. Some editors do this just by moving the cursor across a brace (or paren). - Jay > Date: Fri, 15 Feb 2008 09:18:19 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote:> > I don't really question the usefulness of any given feature, just the > > incremental cost of adding any given feature. One of M3's great > > strengths is that it is low on features, but the ones it has are > > powerful and well chosen.> > > > The comparison I meant in the typing discussion was between C and M3, > > not the length of symbols. C is a bit obsessive about source size, > > which was meaningful back in the day, but today is totally irrelevant. > > Even if you don't use macros on your editor, the amount of time spent > > staring and your code is much greater than the time you spend typing > > it. You could argue that BEGIN/END is easier to read than {/}> > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/{/} > altogether.> > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces.> I could post it here if anyone in interested in such a curiosity.> > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting> WHILE toronto == montreal > could end with> END WHILE toronto ==;> making visual matchin unambiguous.> > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at the > end. They say they keep fprgetting to modify both. But I welcome this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 16:18:11 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:18:11 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. I do NOT assume existing code will get garbage collection without source change. But then again, what does the Boehm collector do? And if I write: a: array of integer; for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not what I'm used to...*) IO.PutInt(a[i]); end in Modula-3, is the codegen a) really banned from and b) really avoids "rewriting" that with pointer arithmetic? I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: unsigned array[n]; for (size_t i = 0 ; i != n ; ++i) { printf("%u\n", array[i]); } vs. unsigned array[n]; for (unsigned* p = array ; p != (array + n) ; ++p) { printf("%u\n", *p); } compilers can often do better with the first. I've heard this. I don't know why. - Jay > Date: Fri, 15 Feb 2008 09:20:42 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote:> > PS The C++ standard committee is actively developing the next C++ > > standard to include garbage collection as part of the spec.> > What are they ever going to do with those autodecremented pointers into > the middle of arrays?> > -- hendrik _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Feb 15 16:31:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 10:31:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <20080215153142.GD3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:18:11PM +0000, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. > I do NOT assume existing code will get garbage collection without source change. > But then again, what does the Boehm collector do? I don't know. I'm mostly pointing out that it will involve radical change in C++ usage. > I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: > > unsigned array[n]; > for (size_t i = 0 ; i != n ; ++i) > { printf("%u\n", array[i]); > } > > vs. > unsigned array[n]; > for (unsigned* p = array ; p != (array + n) ; ++p) > { > printf("%u\n", *p); > } > > compilers can often do better with the first. I've heard this. I don't > know why. Perhaps because it's easier to tell that array[i] is (supposed to be) within the array? I believe C spec requires this (except for some futzing with the address just one element past the array, like array+n) but it's never checked in any C compiler I know of. I once explored the possibility of performing all of these chacks in a C/C++ implementation, and concluded that it would require sufficiently different data representation from the programmers' expectations that it would be essentially useless. One of the main uses of C is to communicate with strange program libraries that use strange in-memory data structures. When they include garbage-collection into C++, I fear the result will be that in the absence of type-safety and array-bound safety, garbage collection will seem to be one more thing that causes programs to crash. -- hendrik From hosking at cs.purdue.edu Fri Feb 15 16:51:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 10:51:43 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B50EDF.8060807@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> Message-ID: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Ah, OK. I don't much delve in pickle-land. Anything I can help with? On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > 1) RTPacking.T and needs to have a separate size for LONGINT, > (which can vary independently of the size of INTEGER). > 2) Variable length values of subrange bounds found in type > descriptions (in TipeDesc.i3) can now have values beyond > what the native word size can represent. > 3) RTType.Kind.Longint (which I presume you, Tony, added recently) > is not handled by Pickles. > > I have done some coding on this, but have been interrupted. > > Tony Hosking wrote: >> Why is LONGINT for pickles not yet supported? > > -- > ------------------------------------------------------------- > 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 hosking at cs.purdue.edu Fri Feb 15 17:13:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:13:53 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <0F7203EA-6D0B-4A5D-BF81-0141ADDFC89A@cs.purdue.edu> Interior references are derived from base pointers -- they can be dealt with or treated conservatively. On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:14:36 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:14:36 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54D818D0-97A3-494E-A329-13690DF2466E@cs.purdue.edu> PS CM3 permits interior pointers into the middle of arrays. The only way they get generated is with VAR parameters, but they do exist. :-) On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:15:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:15:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <1AAD7E29-676A-4C45-93D5-7B52D08968BE@cs.purdue.edu> The directions of these postings are off-topic for the m3devel mailing list. Let's try to get back to questions of Modula-3 development. On Feb 15, 2008, at 10:10 AM, Jay wrote: > Having written a bit of Python..really just a bit..you are all > privy to ALL of the Python I have ever written...I'll bite. > > It's fairly obvious once you write a bit of Python what goes on here. > > First, we all know that we all strive to indent things "correctly". > Now, "correctly" can vary somewhat, but the intent is universal. > Deeper lexical nesting goes with increased indentation. > You can pick the indent size, spaces vs. tabs, where the braces/ > begin/end go, but it's still the same intent. > > Now, when paired with begin/end or braces, you end up with a large > duplication of information. > The one the compiler uses only and the ones human use more. > You get to keep them in sync. Your editor might help a lot. > > What Python does is merely throw out half the data, and require > some consistency on your part for what in other languages the > compiler ignores. > I don't know the exact rules, but they are probably easy to think of. > That is, it could easily allow either spaces or tabs. > > This approach is not bad. But I have two problems: > 1) again, my editor > 2) it's a little wierd and hard to see when you have a whole lot of > closes in a row > > if > print > if > print > if > print > nothing here > > vs. either C or Modula-3. > Perhaps a better approach is to require "end" and require > consistent indentation. > Python also can't cope with an empty statement because of this plus > its lack of semicolons. > You have to say "pass". That's a bit of an indictment. > > As to tabs, the answer is very easy. Never ever use them. > Lots of folks use 4 space tabs, lots of folks use 8 space tabs. > I used to be a 4 space tab guy, but I gave up tabs a few years ago. > The Cygwin code uses 8 space tabs and is therefore unreadable to me. > (I could change my editor setting, and since the 4 space tabs are > pretty rare now, ok.) > > To those who suggested emacs for convenient Modula-3 editing, > sorry, it's not likely going to happen. > I have tried vi and emacs multiple times through the years and I > can't use either. > I use vi just for editing commit comments, which are often pasted > in to the console from notepad anyway. > > My "problem" is that I make heavy use of the arrows, home, end, > page up, page down, control, and shift. > (control can "accelerate" arrows, shift is used for selecting). > And some other ingrained keyboard short cuts like control-f, F3, etc. > I use Visual C++ 5.0 and its support for these keys, plus a little > bit of support for indentation, is excellent. > It could be that the newer versions are better, and I would like > find-and-REPLACE in files, and support for unicode files, but these > aren't worth it so far. Oh, and the find-in-files, minus a replace > option, is excellent, just super duper, I use it constantly. > Nothing else compares. > > The only people I try to get to change editors is people that use > notepad. > > On PPC_DARWIN I make do with TextWrangler. It is ok. (From the > BBEdit folks). > On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. > > If anyone out there is struggling with too-basic editors such as > TextEdit or whatever it's called these days, I'd recommend trying > these. But if you are already using a "programmer's editor", I'll > leave you alone. :) > If anyone knows of something more comparable to Visual C++ 5.0 on > other platforms, I'm eager to hear. > (Maybe under Wine? But that requires x86 I think..) > > Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), > but it starts up slowly on Windows, crashes a bit on Windows, and > isn't being updated.. > > (Trying for "gentle advise" not "advocacy" here.) > > > > incremental cost of adding any given feature. One of M3's great > > I think the problem is more of multiplication than increment. > How do the features interact with each other? > Two features interact very very well -- destructors and exceptions. > And constructors in that mix. > Otherwise not certain. > > > C is a bit obsessive about source size, > > There used to be an assembler that used tabs and a competitor that > used spaces. > The tab guy advertised his much smaller files. :) And I think > therefore faster assembling. > Well, definitely much faster assembling either way, probably not > because of or only because > of the tabs. > > Yes I have that problem with procedures. And modules, and interfaces. > This is where my editor and braces excel. You need to sprinkle in > the matching text. > You type control-brace on a brace and it shows you the matching one. > Some editors do this just by moving the cursor across a brace (or > paren). > > - Jay > > > > > Date: Fri, 15 Feb 2008 09:18:19 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > > > I don't really question the usefulness of any given feature, > just the > > > incremental cost of adding any given feature. One of M3's great > > > strengths is that it is low on features, but the ones it has are > > > powerful and well chosen. > > > > > > The comparison I meant in the typing discussion was between C > and M3, > > > not the length of symbols. C is a bit obsessive about source size, > > > which was meaningful back in the day, but today is totally > irrelevant. > > > Even if you don't use macros on your editor, the amount of time > spent > > > staring and your code is much greater than the time you spend > typing > > > it. You could argue that BEGIN/END is easier to read than {/} > > > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > > disputes about the number of spaces that are equivalent to a tab and > > such, I'd argue for using indentation and dispensing with BEGIN/ > END/{/} > > altogether. > > > > Somewhere I have a C++ program with all the braces left out. If you > > manage to supply the right braces and get it compiled, you end up > > with a program that will do the job of supplying the right braces. > > I could post it here if anyone in interested in such a curiosity. > > > > There's one language I've seen that goes in the opposite direction. > > Every END is followed by an arbitrary amount of text from the > start of > > the construct it closes and a semicolon. This a WHILE loop starting > > WHILE toronto == montreal > > could end with > > END WHILE toronto ==; > > making visual matchin unambiguous. > > > > I've got friends that complain about haveing to type the name if a > > procerure twice in its declaration -- once at the start and once > at the > > end. They say they keep fprgetting to modify both. But I welcome > this > > as a useful check on long-range bracket matching. Forcing it for > > short-range marching, though, is clutter. > > > > -- hendrik > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Fri Feb 15 17:20:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:20:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54998599-6E3D-425C-BA89-7BABBD9508D6@cs.purdue.edu> On Feb 15, 2008, at 10:18 AM, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on > pointers to garbage collected types. If you check the C standard you will see that the only *defined* pointers to array elements are to the elements of the array and the "element" one index beyond the end of the array. Implementations of C are technically free to treat other pointer arithmetic however they like... :-) > I do NOT assume existing code will get garbage collection without > source change. > But then again, what does the Boehm collector do? > > And if I write: > > a: array of integer; > for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not > what I'm used to...*) > IO.PutInt(a[i]); > end > > in Modula-3, is the codegen a) really banned from and b) really avoids > "rewriting" that with pointer arithmetic? Not banned at all with the current GC. So long as a derived reference to the array exists the GC will use it to keep the array alive. From hosking at cs.purdue.edu Fri Feb 15 17:28:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:28:26 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: Rodney, Why does there need to be an entry for LONGINT in RTPacking? I would have thought all packing is done on word-sized units anyway. Each side of the connection can check BITSIZE(LONGINT) to figure out what to do presumably no differently from the way INTEGER is communicated between 32-bit and 64-bit machines. Am I missing something? -- Tony On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > Ah, OK. I don't much delve in pickle-land. Anything I can help with? > > On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >> 1) RTPacking.T and needs to have a separate size for LONGINT, >> (which can vary independently of the size of INTEGER). >> 2) Variable length values of subrange bounds found in type >> descriptions (in TipeDesc.i3) can now have values beyond >> what the native word size can represent. >> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >> is not handled by Pickles. >> >> I have done some coding on this, but have been interrupted. >> >> Tony Hosking wrote: >>> Why is LONGINT for pickles not yet supported? >> >> -- >> ------------------------------------------------------------- >> 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 rodney.bates at wichita.edu Fri Feb 15 21:50:27 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 14:50:27 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: <47B5FB13.7070407@wichita.edu> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, etc. only works for getting object layouts as on the machine executing the code, which is all that is needed when writing a pickle. When reading, Pickle code needs to know the layouts of a type both as it is on the reading machine and as it was on the machine that wrote the pickle. The type description that the compiler generates is excerpted and contains no field displacements, just lists of field types (which are either recursive type descriptions or builtin types). So it is independent of word sizes, etc. Pickles regenerates the displacements using the few target machine characteristics in a RTPacking.T It traverses a type description and simultaneously computes two sets of field displacements, both as they are on the reading machine and on the writing machine. For the latter, the value of RTPacking.T is (after a compact bit encoding) stored in the header of the pickle file. For the former, it's gotten by techniques like using BITSIZE. This is actually all done in RTTipe, part of m3core, and called by Pickle code. This is very fragile. RTTipe has to duplicate the compiler's layout behavior. There is no shared code. Making it common would involve quite a bit of rework, as the two use substantially different data structure and code organization. It will be obvious what kind of bit damage could occur if the two algorithms didn't agree. This is why I am obsessing over LAZYALIGN. I have been comparing the field displacement computations in RTTipe and in the compiler. The former is oblivious to LAZYALIGN. Note that all this is required even without any packing of small fields within words. E.G., a record with two INTEGER fields, pickled on a 32-bit machine and unpickled on a 64. Tony Hosking wrote: > Rodney, > > Why does there need to be an entry for LONGINT in RTPacking? I would > have thought all packing is done on word-sized units anyway. Each side > of the connection can check BITSIZE(LONGINT) to figure out what to do > presumably no differently from the way INTEGER is communicated between > 32-bit and 64-bit machines. Am I missing something? > > -- Tony > > On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >> >> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >> >>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>> (which can vary independently of the size of INTEGER). >>> 2) Variable length values of subrange bounds found in type >>> descriptions (in TipeDesc.i3) can now have values beyond >>> what the native word size can represent. >>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>> is not handled by Pickles. >>> >>> I have done some coding on this, but have been interrupted. >>> >>> Tony Hosking wrote: >>> >>>> Why is LONGINT for pickles not yet supported? >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > > -- ------------------------------------------------------------- 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 Fri Feb 15 22:32:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 15 Feb 2008 22:32:05 +0100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B5FB13.7070407@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> Message-ID: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Perhaps we should check-in this description somewhere near the actual code? Or is there enough documentation already? Olaf PS: Based on your description, I'd say we should abandon LAZYALIGN. Or at least put a big sticker on that it will break pickles. Quoting "Rodney M. Bates" : > The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, > etc. only works for getting object layouts as on the machine executing > the code, which is all that is needed when writing a pickle. > > When reading, Pickle code needs to know the layouts of a type both as > it is on the reading machine and as it was on the machine that wrote > the pickle. The type description that the compiler generates is > excerpted and contains no field displacements, just lists of field > types (which are either recursive type descriptions or builtin types). > So it is independent of word sizes, etc. > > Pickles regenerates the displacements using the few target machine > characteristics in a RTPacking.T It traverses a type description and > simultaneously computes two sets of field displacements, both as they > are on the reading machine and on the writing machine. For the latter, > the value of RTPacking.T is (after a compact bit encoding) stored in the > header of the pickle file. For the former, it's gotten by techniques like > using BITSIZE. This is actually all done in RTTipe, part of m3core, and > called by Pickle code. > > This is very fragile. RTTipe has to duplicate the compiler's layout > behavior. There is no shared code. Making it common would involve > quite a bit of rework, as the two use substantially different data > structure and code organization. It will be obvious what kind of bit > damage could occur if the two algorithms didn't agree. > > This is why I am obsessing over LAZYALIGN. I have been comparing the > field displacement computations in RTTipe and in the compiler. The > former is oblivious to LAZYALIGN. > > Note that all this is required even without any packing of small fields > within words. E.G., a record with two INTEGER fields, pickled on a > 32-bit machine and unpickled on a 64. > > Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I >> would have thought all packing is done on word-sized units anyway. >> Each side of the connection can check BITSIZE(LONGINT) to figure >> out what to do presumably no differently from the way INTEGER is >> communicated between 32-bit and 64-bit machines. Am I missing >> something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> > > -- > ------------------------------------------------------------- > 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 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Feb 15 23:06:24 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:06:24 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Message-ID: <47B60CE0.8050506@wichita.edu> I'll put it in comments in the code. I am sure I can fix it to handle LAZYALIGN too, just not sure whether I can do it without requiring existing pickle files to be regenerated and/or existing code that reads/writes pickles to need recompilation. Anybody on this list who has code that might be affected if pickles or compiled code were invalidated by a change? I do propose we change the way of telling the compiler to do LAZYALIGN so that it is a property of a type and affects all variables of that type. Olaf Wagner wrote: > Perhaps we should check-in this description somewhere near the > actual code? Or is there enough documentation already? > > Olaf > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > Or at least put a big sticker on that it will break pickles. > > Quoting "Rodney M. Bates" : > >> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >> etc. only works for getting object layouts as on the machine executing >> the code, which is all that is needed when writing a pickle. >> >> When reading, Pickle code needs to know the layouts of a type both as >> it is on the reading machine and as it was on the machine that wrote >> the pickle. The type description that the compiler generates is >> excerpted and contains no field displacements, just lists of field >> types (which are either recursive type descriptions or builtin types). >> So it is independent of word sizes, etc. >> >> Pickles regenerates the displacements using the few target machine >> characteristics in a RTPacking.T It traverses a type description and >> simultaneously computes two sets of field displacements, both as they >> are on the reading machine and on the writing machine. For the latter, >> the value of RTPacking.T is (after a compact bit encoding) stored in the >> header of the pickle file. For the former, it's gotten by techniques >> like >> using BITSIZE. This is actually all done in RTTipe, part of m3core, and >> called by Pickle code. >> >> This is very fragile. RTTipe has to duplicate the compiler's layout >> behavior. There is no shared code. Making it common would involve >> quite a bit of rework, as the two use substantially different data >> structure and code organization. It will be obvious what kind of bit >> damage could occur if the two algorithms didn't agree. >> >> This is why I am obsessing over LAZYALIGN. I have been comparing the >> field displacement computations in RTTipe and in the compiler. The >> former is oblivious to LAZYALIGN. >> >> Note that all this is required even without any packing of small fields >> within words. E.G., a record with two INTEGER fields, pickled on a >> 32-bit machine and unpickled on a 64. >> >> Tony Hosking wrote: >> >>> Rodney, >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> would have thought all packing is done on word-sized units anyway. >>> Each side of the connection can check BITSIZE(LONGINT) to figure >>> out what to do presumably no differently from the way INTEGER is >>> communicated between 32-bit and 64-bit machines. Am I missing >>> something? >>> >>> -- Tony >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> (which can vary independently of the size of INTEGER). >>>>> 2) Variable length values of subrange bounds found in type >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> what the native word size can represent. >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>>> is not handled by Pickles. >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> >>> >> >> -- >> ------------------------------------------------------------- >> 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 > > > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:08:46 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:08:46 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> Message-ID: <47B60D6E.8080704@wichita.edu> So how is lazy alignment invoked for these types? In my grepping and reading in the compiler, I saw internal lazy alignment booleans turned on only by the pragma. Darko wrote: > The alignment rules are correctly associated with a type. I think the > pragma can be removed. There are no pickles anywhere of these types. > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:41:09 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:41:09 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <47B61505.5080708@wichita.edu> I view this as more significant than it would first appear. More important than readability is that delimiters with several letters in all caps are more PROMINENT. This makes it quicker seeing the overall structure of a piece of code before looking at the deeper details such as which variable is being manipulated. Up to now, every person I have discussed it with who has spent enough time coding with this style of delimiters to get over their initial aversion has agreed the prominence of all caps makes the code structure easier to see quickly. Even Ada programmers who had significant prior experience in Modula-2 have preferred all caps in Ada (Ada is case- insensitive, so you can do it as you please.) As for readability, I recall seeing research some years back that showed all caps are less readable than lower case, that is, people read all caps slower and/or with less accuracy. For the delimiters, prominence is more important, especially since their vocabulary is far smaller than that of identifiers and doesn't change from program to program. As for esthetics, speaking for myself, after many years, I still think all caps reserved words are uglier than mud fences, but I happily accept that as the cost of easier scanning of code. It would be nice we had a standard character code that could handle lower case, bold face, as in the Algol 60 "publication language". That would be prominent and look great too. Of course, someone could undermine it all by making all the identifiers all caps too, loosing the quickly spotted reserved words, reducing readability where it matters more, and, IMO looking even uglier. Fortunately, Modula-3 culture seems to prevent that. Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} but I > think the more important point is that this issue is not a significant > one. -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:52:22 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:52:22 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <47B617A6.80305@wichita.edu> Darko wrote: > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. "It's what everybody is doing" motivates lemmings to jump off cliffs into the ocean and drown (according to the apparently exaggerated legend.) Thinking people need better reasons than popularity. > You have to do more than list features of C or C++ and your opinions on > them. You have to provide some rationale as to their benefit which > convinces people. Sadly, in my experience, most people are so deeply committed to lemming logic, that any attempt at engaging them in a polite but serious discussion about programming languages or giving real rationale is almost always dismissed, either as "That's just religion", or "This is what everybody is doing, ergo it has to be the right way." -- ------------------------------------------------------------- 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 mika at async.caltech.edu Fri Feb 15 23:58:55 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 14:58:55 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 13:34:27 EST." <20080214183427.GB30167@topoi.pooq.com> Message-ID: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> I just have to add a small comment on syntax, in response to how weird M3's syntax is, etc. One of the nice thing when I was teaching intro programming was that "serious" CS books (and a large fraction of academic publications) still use a kind of standard pseudocode that is based on Algol. And that pseudocode looks a lot more like Modula-3 than it looks like C! No explanation of braces or the fact that when you see "=" in the pseudocode you want "==" in the machine-readable version, and when you see ":=" you want "=". What your video game developer friend needs is to do exercise #12 in section 2.3.5 in Knuth. (There are references to three existing solutions in the answer key.) Mika hendrik at topoi.pooq.com writes: >On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > >I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and >'END'. > >Natural languages evolve in the direction of having the mopst-oftern >used words be the shortest. This makes it possible to say muc in less >space and time. And it makes it easier to get an overview of a >program whose physical size is becoming inconvenient. Just haveing >the code be readable and seeing enough of its context makes >debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > >Stack allocation of objects is not such a big issue in C++. But it can >be a big issue in those programs where split-second real-time >interaction is an issue. Yes, I know this is the traditional argument >against garbage collection, and that it is usually based on FUD rather >than reality. But I have recently been in close contact with a >programmer of video games, and for some of them the fraction-of-a-second >pauses are a real problem. He really *wants* to write his games in a >decent language, and he knows that C is not one. > >But every time he avoids heap allocation he delays the pause. If >he can delay it enough, it's a win. If he can delay it altogether, >that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing >*and* reduce bugs, just by making code more readable. > >I doubt that typing "PROC" instead of "PROCEDURE", for example, is >likely to introdice bugs. Not typing '{' instead of "BEGIN". Using >special characters and lower-case keywords is likely to reduce bugs, >because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > >I think before I write code. I don't stop thinking when I start >writing code, and I like to record my thoughts as I think. The less >typing I need to do, the better I can get visual feedback on my >thoughts while thinking. Sometimes the typing gets so tedious I get >bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > >No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > >Enough people use it that it has become a fixture in the programming >world. If you want to reuse existing code instead of always writing >new, you are pretty much forced into some kind of interfacing between C >and a reasonable language. The convenience of this interfacing can well >determine whether the reasonable language is feasible for a specific >application. > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 00:17:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 18:17:41 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> References: <20080214183427.GB30167@topoi.pooq.com> <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> Message-ID: <20080215231741.GA4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: > > What your video game developer friend needs is to do exercise #12 > in section 2.3.5 in Knuth. (There are references to three existing > solutions in the answer key.) Is that the one one completely concurrent garbage collection? Unfortunately, he wants to write video games, not implement programming languages. But ... I think he's tempted. I still feel I have to warn him of the time I wanted to write an applocation and got side-tracked into writing the language in which the application would be easy to write. I never got back to the application. I don't even remember what it was. That was in the 1960's. I'm still stuck on languages. -- hendrik From darko at darko.org Sat Feb 16 00:34:47 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:34:47 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <25955172-E857-4B24-8D51-3701C7353687@darko.org> I'm sticking to my view about lexical arbitrariness, but on that basis, I'd really like to see an alternate syntax for M3, one that looks almost exactly like C, but roughly keeps the existing statement form. I think it would make the language much more palatable to C programmers and the like and would remove what is a silly barrier to broader adaption. We could call the syntax 'Modula-C'. On 16/02/2008, at 1:18 AM, hendrik at topoi.pooq.com wrote: > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: >> I don't really question the usefulness of any given feature, just the >> incremental cost of adding any given feature. One of M3's great >> strengths is that it is low on features, but the ones it has are >> powerful and well chosen. >> >> The comparison I meant in the typing discussion was between C and M3, >> not the length of symbols. C is a bit obsessive about source size, >> which was meaningful back in the day, but today is totally >> irrelevant. >> Even if you don't use macros on your editor, the amount of time spent >> staring and your code is much greater than the time you spend typing >> it. You could argue that BEGIN/END is easier to read than {/} > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/ > {/} > altogether. > > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces. > I could post it here if anyone in interested in such a curiosity. > > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting > WHILE toronto == montreal > could end with > END WHILE toronto ==; > making visual matchin unambiguous. > > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at > the > end. They say they keep fprgetting to modify both. But I welcome > this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter. > > -- hendrik From mika at async.caltech.edu Sat Feb 16 00:38:09 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:38:09 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Fri, 15 Feb 2008 14:50:27 CST." <47B5FB13.7070407@wichita.edu> Message-ID: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Hi Rodney, I am not sure if I am reading your email entirely correctly, but I think so... you're trying to figure out things like offsets so the Pickle runtime can re-build arbitrary data structures. When we were doing some concurrent programming in my group about ten years ago, we were using a user-level threading system (very similar but not identical to the old user-level threads in M3) and we needed to figure out the location of the stack pointer in a C jmp_buf. We just wrote a program to do it... Could you do that? Write some arbitrary data whose bit pattern you know to a field, cast it to char * (or some such), and search for the bit pattern? Do it over and over with random data, and there you go... Mika "Rodney M. Bates" writes: >The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >etc. only works for getting object layouts as on the machine executing >the code, which is all that is needed when writing a pickle. > >When reading, Pickle code needs to know the layouts of a type both as >it is on the reading machine and as it was on the machine that wrote >the pickle. The type description that the compiler generates is >excerpted and contains no field displacements, just lists of field >types (which are either recursive type descriptions or builtin types). >So it is independent of word sizes, etc. > >Pickles regenerates the displacements using the few target machine >characteristics in a RTPacking.T It traverses a type description and >simultaneously computes two sets of field displacements, both as they >are on the reading machine and on the writing machine. For the latter, >the value of RTPacking.T is (after a compact bit encoding) stored in the >header of the pickle file. For the former, it's gotten by techniques like >using BITSIZE. This is actually all done in RTTipe, part of m3core, and >called by Pickle code. > >This is very fragile. RTTipe has to duplicate the compiler's layout >behavior. There is no shared code. Making it common would involve >quite a bit of rework, as the two use substantially different data >structure and code organization. It will be obvious what kind of bit >damage could occur if the two algorithms didn't agree. > >This is why I am obsessing over LAZYALIGN. I have been comparing the >field displacement computations in RTTipe and in the compiler. The >former is oblivious to LAZYALIGN. > >Note that all this is required even without any packing of small fields >within words. E.G., a record with two INTEGER fields, pickled on a >32-bit machine and unpickled on a 64. > >Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I would >> have thought all packing is done on word-sized units anyway. Each side >> of the connection can check BITSIZE(LONGINT) to figure out what to do >> presumably no differently from the way INTEGER is communicated between >> 32-bit and 64-bit machines. Am I missing something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> > >-- >------------------------------------------------------------- >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 darko at darko.org Sat Feb 16 00:41:51 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:41:51 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B60D6E.8080704@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> <47B60D6E.8080704@wichita.edu> Message-ID: <385E6BF4-B476-4060-9EAD-DE1DCC74A2D9@darko.org> It's turned on at the platform level only. The result is that packed structures are packed as tightly as possible. On 16/02/2008, at 9:08 AM, Rodney M. Bates wrote: > So how is lazy alignment invoked for these types? In my grepping > and reading > in the compiler, I saw internal lazy alignment booleans turned on only > by the pragma. > > Darko wrote: >> The alignment rules are correctly associated with a type. I think >> the pragma can be removed. There are no pickles anywhere of these >> types. > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Sat Feb 16 00:51:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:51:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 10:34:47 +1100." <25955172-E857-4B24-8D51-3701C7353687@darko.org> Message-ID: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Darko writes: >I'm sticking to my view about lexical arbitrariness, but on that >basis, I'd really like to see an alternate syntax for M3, one that >looks almost exactly like C, but roughly keeps the existing statement >form. I think it would make the language much more palatable to C >programmers and the like and would remove what is a silly barrier to >broader adaption. We could call the syntax 'Modula-C'. This is getting a bit silly, and I apologize to everyone reading this about wasting their time, but I just have to show you the following file. It is a header file from the original sources of "sh" (this copy is from 4.3 TAHOE UNIX, but of course the code is much older than that). After that, blok.c, an example of "Bournegol" in use. So, you want the opposite, huh? Mika /* mac.h 4.3 87/10/26 */ # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #define LOCAL static #define PROC extern #define TYPE typedef #define STRUCT TYPE struct #define UNION TYPE union #define REG register #define IF if( #define THEN ){ #define ELSE } else { #define ELIF } else if ( #define FI ;} #define BEGIN { #define END } #define SWITCH switch( #define IN ){ #define ENDSW } #define FOR for( #define WHILE while( #define DO ){ #define OD ;} #define REP do{ #define PER }while( #undef DONE #define DONE ); #define LOOP for(;;){ #define POOL } #define SKIP ; #define DIV / #define REM % #define NEQ ^ #define ANDF && #define ORF || #define TRUE (-1) #define FALSE 0 #define LOBYTE 0377 #define STRIP 0177 #define QUOTE 0200 #define EOF 0 #define NL '\n' #define SP ' ' #define LQ '`' #define RQ '\'' #define MINUS '-' #define COLON ':' #ifndef lint static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; #endif # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #include "defs.h" /* * storage allocator * (circular first fit strategy) */ #define BUSY 01 #define busy(x) (Rcheat((x)->word)&BUSY) POS brkincr=BRKINCR; BLKPTR blokp; /*current search pointer*/ BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ ADDRESS alloc(nbytes) POS nbytes; { REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); LOOP INT c=0; REG BLKPTR p = blokp; REG BLKPTR q; REP IF !busy(p) THEN WHILE !busy(q = p->word) DO p->word = q->word OD IF ADR(q)-ADR(p) >= rbytes THEN blokp = BLK(ADR(p)+rbytes); IF q > blokp THEN blokp->word = p->word; FI p->word=BLK(Rcheat(blokp)|BUSY); return(ADR(p+1)); FI FI q = p; p = BLK(Rcheat(p->word)&~BUSY); PER p>q ORF (c++)==0 DONE addblok(rbytes); POOL } VOID addblok(reqd) POS reqd; { IF stakbas!=staktop THEN REG STKPTR rndstak; REG BLKPTR blokstak; pushstak(0); rndstak=round(staktop,BYTESPERWORD); blokstak=BLK(stakbas)-1; blokstak->word=stakbsy; stakbsy=blokstak; bloktop->word=BLK(Rcheat(rndstak)|BUSY); bloktop=BLK(rndstak); FI reqd += brkincr; reqd &= ~(brkincr-1); blokp=bloktop; bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); bloktop->word=BLK(ADR(end)+1); BEGIN REG STKPTR stakadr=STK(bloktop+2); staktop=movstr(stakbot,stakadr); stakbas=stakbot=stakadr; END } VOID free(ap) BLKPTR ap; { REG BLKPTR p; IF (p=ap) ANDF pword) &= ~BUSY; FI } #ifdef DEBUG chkbptr(ptr) BLKPTR ptr; { INT exf=0; REG BLKPTR p = end; REG BLKPTR q; INT us=0, un=0; LOOP q = Rcheat(p->word)&~BUSY; IF p==ptr THEN exf++ FI IF qbloktop THEN abort(3) FI IF p==bloktop THEN break FI IF busy(p) THEN us += q-p; ELSE un += q-p; FI IF p>=q THEN abort(4) FI p=q; POOL IF exf==0 THEN abort(1) FI prn(un); prc(SP); prn(us); prc(NL); } #endif From mika at async.caltech.edu Sat Feb 16 00:56:00 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:56:00 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Fri, 15 Feb 2008 18:17:41 EST." <20080215231741.GA4216@topoi.pooq.com> Message-ID: <200802152356.m1FNu0F3034075@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: >> >> What your video game developer friend needs is to do exercise #12 >> in section 2.3.5 in Knuth. (There are references to three existing >> solutions in the answer key.) > >Is that the one one completely concurrent garbage collection? Right, I think that's what Tony was (indirectly) referring to, as well. The publication dates on the three solutions range from 1975 to 1978... > >Unfortunately, he wants to write video games, not implement programming >languages. But ... I think he's tempted. > >I still feel I have to warn him of the time I wanted to write an >applocation and got side-tracked into writing the language in which the >application would be easy to write. I never got back to the >application. I don't even remember what it was. That was in the >1960's. I'm still stuck on languages. And, if you ask me, languages are still stuck! > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:18:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:18:30 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B61505.5080708@wichita.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <47B61505.5080708@wichita.edu> Message-ID: <20080216001830.GB4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 04:41:09PM -0600, Rodney M. Bates wrote: > I view this as more significant than it would first appear. More > important than readability is that delimiters with several letters > in all caps are more PROMINENT. This makes it quicker seeing the > overall structure of a piece of code before looking at the deeper > details such as which variable is being manipulated. > > Up to now, every person I have discussed it with who has spent enough > time coding with this style of delimiters to get over their initial > aversion has agreed the prominence of all caps makes the code structure > easier to see quickly. Even Ada programmers who had significant prior > experience in Modula-2 have preferred all caps in Ada (Ada is case- > insensitive, so you can do it as you please.) > > As for readability, I recall seeing research some years back that > showed all caps are less readable than lower case, that is, people > read all caps slower and/or with less accuracy. For the delimiters, > prominence is more important, especially since their vocabulary is > far smaller than that of identifiers and doesn't change from program > to program. As long as you don't have both else and elsf as keywords in the same language! It works find in lower-case but is hopeless in upper. > As for esthetics, speaking for myself, after many years, I still think > all caps reserved words are uglier than mud fences, but I happily accept > that as the cost of easier scanning of code. > > It would be nice we had a standard character code that could handle > lower case, bold face, as in the Algol 60 "publication language". > That would be prominent and look great too. Really, there should be nothing preventing us from writing editors that display all-upper-case words as red lower-case words, and m3-to-ps converters that print them as bold-face lower-case. -- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:25:15 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:25:15 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <25955172-E857-4B24-8D51-3701C7353687@darko.org> <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <20080216002515.GC4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:51:43PM -0800, Mika Nystrom wrote: > Darko writes: > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? Yeah. Steve Bourne did an Algol 68 variant in Cambridge before he went to Bell Labs. He did his bit here to make C look more like Algol 68C. Except A68 allows things to be a lot more terse than here. I think A68 had the right idea about syntax. Except that it was horrible to parse. -- hendrik From darko at darko.org Sat Feb 16 08:30:29 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 18:30:29 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> I'm not sure what you're getting at or if I'm missing something witty. I've said the form of the keywords makes little or no difference in my opinion. In my mail you quote I say there should be a C like syntax for M3 as well as the existing one. I wasn't being sarcastic. It's a matter of taste. I write in both all the time and it doesn't have any impact on me, I go almost entirely by indentation, which I think is very important. The indentation is pretty awful in code you posted but it could me my mailer. On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > Darko writes: >> I'm sticking to my view about lexical arbitrariness, but on that >> basis, I'd really like to see an alternate syntax for M3, one that >> looks almost exactly like C, but roughly keeps the existing statement >> form. I think it would make the language much more palatable to C >> programmers and the like and would remove what is a silly barrier to >> broader adaption. We could call the syntax 'Modula-C'. > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? > > Mika > > > /* mac.h 4.3 87/10/26 */ > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #define LOCAL static > #define PROC extern > #define TYPE typedef > #define STRUCT TYPE struct > #define UNION TYPE union > #define REG register > > #define IF if( > #define THEN ){ > #define ELSE } else { > #define ELIF } else if ( > #define FI ;} > > #define BEGIN { > #define END } > #define SWITCH switch( > #define IN ){ > #define ENDSW } > #define FOR for( > #define WHILE while( > #define DO ){ > #define OD ;} > #define REP do{ > #define PER }while( > #undef DONE > #define DONE ); > #define LOOP for(;;){ > #define POOL } > > > #define SKIP ; > #define DIV / > #define REM % > #define NEQ ^ > #define ANDF && > #define ORF || > > #define TRUE (-1) > #define FALSE 0 > #define LOBYTE 0377 > #define STRIP 0177 > #define QUOTE 0200 > > #define EOF 0 > #define NL '\n' > #define SP ' ' > #define LQ '`' > #define RQ '\'' > #define MINUS '-' > #define COLON ':' > > > > #ifndef lint > static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; > #endif > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #include "defs.h" > > > /* > * storage allocator > * (circular first fit strategy) > */ > > #define BUSY 01 > #define busy(x) (Rcheat((x)->word)&BUSY) > > POS brkincr=BRKINCR; > BLKPTR blokp; /*current search pointer*/ > BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ > > > > ADDRESS alloc(nbytes) > POS nbytes; > { > REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); > > LOOP INT c=0; > REG BLKPTR p = blokp; > REG BLKPTR q; > REP IF !busy(p) > THEN WHILE !busy(q = p->word) DO p->word = q->word OD > IF ADR(q)-ADR(p) >= rbytes > THEN blokp = BLK(ADR(p)+rbytes); > IF q > blokp > THEN blokp->word = p->word; > FI > p->word=BLK(Rcheat(blokp)|BUSY); > return(ADR(p+1)); > FI > FI > q = p; p = BLK(Rcheat(p->word)&~BUSY); > PER p>q ORF (c++)==0 DONE > addblok(rbytes); > POOL > } > > VOID addblok(reqd) > POS reqd; > { > IF stakbas!=staktop > THEN REG STKPTR rndstak; > REG BLKPTR blokstak; > > pushstak(0); > rndstak=round(staktop,BYTESPERWORD); > blokstak=BLK(stakbas)-1; > blokstak->word=stakbsy; stakbsy=blokstak; > bloktop->word=BLK(Rcheat(rndstak)|BUSY); > bloktop=BLK(rndstak); > FI > reqd += brkincr; reqd &= ~(brkincr-1); > blokp=bloktop; > bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); > bloktop->word=BLK(ADR(end)+1); > BEGIN > REG STKPTR stakadr=STK(bloktop+2); > staktop=movstr(stakbot,stakadr); > stakbas=stakbot=stakadr; > END > } > > VOID free(ap) > BLKPTR ap; > { > REG BLKPTR p; > > IF (p=ap) ANDF p THEN Lcheat((--p)->word) &= ~BUSY; > FI > } > > #ifdef DEBUG > chkbptr(ptr) > BLKPTR ptr; > { > INT exf=0; > REG BLKPTR p = end; > REG BLKPTR q; > INT us=0, un=0; > > LOOP > q = Rcheat(p->word)&~BUSY; > IF p==ptr THEN exf++ FI > IF qbloktop THEN abort(3) FI > IF p==bloktop THEN break FI > IF busy(p) > THEN us += q-p; > ELSE un += q-p; > FI > IF p>=q THEN abort(4) FI > p=q; > POOL > IF exf==0 THEN abort(1) FI > prn(un); prc(SP); prn(us); prc(NL); > } > #endif From jayk123 at hotmail.com Sat Feb 16 08:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 07:34:27 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: > The indentation is pretty awful in code you posted but > it could me my mailer. Yep..it was eight space tabs at every level for me. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Feb 16 10:42:28 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 01:42:28 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 18:30:29 +1100." <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> "If Steve Bourne could turn C into Algol using cpp, I'm sure you can figure out how to turn Algol[Modula] back into C using <...>"... If you think it would help acceptance of Modula-3, I don't see why not? I copied the code exactly the way it came off the old half-inch tape from Berkeley. Darko writes: >I'm not sure what you're getting at or if I'm missing something witty. >I've said the form of the keywords makes little or no difference in my >opinion. In my mail you quote I say there should be a C like syntax >for M3 as well as the existing one. I wasn't being sarcastic. It's a >matter of taste. I write in both all the time and it doesn't have any >impact on me, I go almost entirely by indentation, which I think is >very important. The indentation is pretty awful in code you posted but >it could me my mailer. > >On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: ... From darko at darko.org Sat Feb 16 11:10:40 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 21:10:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> References: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> Message-ID: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> If you like the idea, maybe you'd like join me in working out what such a syntax would look like? Note that I want to keep the structure the same, so no assignments in expressions, for example. Also, would C programmers revolt at not having post and pre increment, also inside expressions (as statements would be ok)? Requiring some sort of EVAL statement? I guess the big question is whether removing these things would make the whole idea unacceptable to the target audience. Does the Algol syntax serve a purpose in making it clear that it isn't C? On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > > "If Steve Bourne could turn C into Algol using cpp, I'm sure you > can figure out how to turn Algol[Modula] back into C using <...>"... > > If you think it would help acceptance of Modula-3, I don't see why > not? > > I copied the code exactly the way it came off the old half-inch > tape from Berkeley. > > Darko writes: >> I'm not sure what you're getting at or if I'm missing something >> witty. >> I've said the form of the keywords makes little or no difference in >> my >> opinion. In my mail you quote I say there should be a C like syntax >> for M3 as well as the existing one. I wasn't being sarcastic. It's a >> matter of taste. I write in both all the time and it doesn't have any >> impact on me, I go almost entirely by indentation, which I think is >> very important. The indentation is pretty awful in code you posted >> but >> it could me my mailer. >> >> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > ... From jayk123 at hotmail.com Sat Feb 16 20:30:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:30:01 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*) Without those lines commented out, only ever one file gets compiled. The process create for the second cm3cg fails (but not for the first as). Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything. Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle? I figured this out with strace. The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly. For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 20:37:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:37:46 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 21:31:53 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 20:31:53 +0000 Subject: [M3devel] FW: NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: seems to have gotten truncated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Feb 17 06:43:38 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 21:43:38 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sat, 16 Feb 2008 21:10:40 +1100." <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> Message-ID: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Well I used to be mostly a C programmer but I long since weaned myself off that syntax :) Your point of the post- and pre-increment might be a bit difficult for C programmers to stomach, but... well it is probably hard to tell what programmers will hate and what they will love. Wouldn't a way to go about it be to take the Modula-3 BNF and modify the rules as needed? Would you like to be able to convert back and forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case all the keywords, convert the braces appropriately (a bit tricky since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO BEGIN END, so braces map only to the ENDs, not BEGINs (for the most part)). Type "attributes"(is that the right word?) are also an area where Modula-3 is significantly different from the C family. In C, you write int *a, *b, c; we have REF INTEGER a, b; INTEGER c; And arrays? VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; I prefer Algol syntax myself but I could definitely see that there might be people who would prefer a syntax mapped to C. One might be able to sneak Modula-3 into places where it wouldn't otherwise be used... Would it be possible to make "m3c" close enough in syntax that some simple C header files could be processed? Am I just being ridiculous now? A compiler that can process both C and Modula-3 in the same file? Python, by the way, provides some interesting hooks for C programs to interact with the Python garbage collector. Something similar could be done here. (But there is far less reason to write C code to plug into M3 than there is to write it to plug into Python.) Mika Darko writes: >If you like the idea, maybe you'd like join me in working out what >such a syntax would look like? Note that I want to keep the structure >the same, so no assignments in expressions, for example. Also, would C >programmers revolt at not having post and pre increment, also inside >expressions (as statements would be ok)? Requiring some sort of EVAL >statement? I guess the big question is whether removing these things >would make the whole idea unacceptable to the target audience. Does >the Algol syntax serve a purpose in making it clear that it isn't C? > > >On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > >> >> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >> can figure out how to turn Algol[Modula] back into C using <...>"... >> >> If you think it would help acceptance of Modula-3, I don't see why >> not? >> >> I copied the code exactly the way it came off the old half-inch >> tape from Berkeley. >> >> Darko writes: >>> I'm not sure what you're getting at or if I'm missing something >>> witty. >>> I've said the form of the keywords makes little or no difference in >>> my >>> opinion. In my mail you quote I say there should be a C like syntax >>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>> matter of taste. I write in both all the time and it doesn't have any >>> impact on me, I go almost entirely by indentation, which I think is >>> very important. The indentation is pretty awful in code you posted >>> but >>> it could me my mailer. >>> >>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >> ... From hendrik at topoi.pooq.com Sun Feb 17 07:29:03 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 01:29:03 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217062903.GA24856@topoi.pooq.com> On Sat, Feb 16, 2008 at 09:43:38PM -0800, Mika Nystrom wrote: > > > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; The declarator syntax in C was a mistake. Let's not perpetuate it. -- hendrik From jayk123 at hotmail.com Sun Feb 17 09:47:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 08:47:52 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Nevermind, of course, I should have known, even though I'm working on fixing the stat struct (probably to blame for files always being out of date) and thought I might have it right, I should have known, I have it too small and the next variable is getting overwritten, causing us to close(0).. If I put in arbitrary large padding at the end, it grows enough to cover up the problem..now to get it right.. null_fd and the entire struct stat need not be globals, just the dev field...of course optimize that and I would have a stack corruption instead, not sure it would have been harder or easier to figure out..I should have started at the bottom of the system and gotten all the headers right in the first place....sigh. VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN null_done := TRUE; null_fd := Unix.open( M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, ADR(null_stat)); RTIO.PutText("2 null_fd is " & Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); and then close 0 here oops IF result # 0 THEN null_fd := -1 END From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 17 10:30:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 10:30:01 +0100 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Quoting Jay : > Nevermind, of course, I should have known, even though I'm working > on fixing the stat struct (probably to blame for files always being > out of date) and thought I might have it right, I should have known, > I have it too small and the next variable is getting overwritten, > causing us to close(0).. Yes, the C interfaces are the place where ports are most likely to be broken. There are no checks there; it's completely unsafe. I wonder if one could write a checker that compares the sizes of the most important structures in C and M3, but that would probably not be trivial. > If I put in arbitrary large padding at the end, it grows enough to > cover up the problem..now to get it right.. > null_fd and the entire struct stat need not be globals, just the dev > field...of course optimize that and I would have a stack corruption > instead, not sure it would have been harder or easier to figure > out..I should have started at the bottom of the system and gotten > all the headers right in the first place....sigh. Yes, it's always a good idea to get the base right at the start. On the other hand, you will usually return there during ant porting, regardless of your best efforts ;-) > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; > > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > null_done := TRUE; null_fd := Unix.open( > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > and then close 0 here oops IF result # 0 THEN null_fd := -1 END [Could you try to persuade your mailer to produce a readable text form besides HTML? If not it looks like that :-(] Anyway, as your previous posting asked about a change in general POSIX support files, I'd really advise you to try out such changes on at least one other platform (e.g. Linux), however innocuous they may seem. Thanks for all the work, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Feb 17 10:57:15 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 09:57:15 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Message-ID: No need for a change in platform-independent code now. My question was sort of "can anyone else try this out, I'm lazy". But I looked up the definition of dup/dup2 and decided Cygwin wasn't doing anything wrong, looked at the strace, saw we were closing 0, started some RTIO... and if IsDebuggerPresent, DebugBreak and finally realized of course what was happening. (the debugging options are really not good. I couldn't even see the globals in gdb, neither of the obvious names worked...I was doing a little debugging in cdb as well and found a crashing bug in it, very very very unusual) Writing a struct checker should actually be pretty easy. The trick is probably mainly to limit the dependencies so it can work when much of the system is broken, or to use a cross strategy if possible..it helps that NT386 supports two sort of platforms/targets/configurations, so you can cross with a smaller context switch. :) I'm not sure how to get field offsets in Modula-3 but if you get as far as having the compiler working, it can generate C with assertions as to sizes and offsets. The compiler's dependency on stat is "the problem". Again I like that idea of wrapping C in C, to expose a portable interface.Of course, it's inefficient. The direct exporting of C interfaces, when they are /correct/ is pretty efficient. NT386GNU should be just about "self hosting" now -- able to build a "min" distribution and then "upgrade". Small hacks in pylib.py needed that might break Win32, no big deal, it's "just the scripts". :) Next steps will be: a) consider changing the "naming conventions" it's still foo.lib and not foo.a, foo.dll and not foo.so. b) see if X Windows works (stuff builds) c) the small set and bitmap bugs (running the tests!) I do have one more commit to enable stuff, a small one, where the Slash is determine at runtime in slightly more code. SL is already determined at runtime, but M3Path maps naming convensions (foo.lib vs. libfoo.a, foo.dll vs. foo.so) to also determine slashes. It might even work if they were escaped, but what I have is a good solution. (if I figure I can ramble here, since I'm on topic. :) ) - Jay > Date: Sun, 17 Feb 2008 10:30:01 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] NT386GNU status/fishing for guesses..> > Quoting Jay :> > > Nevermind, of course, I should have known, even though I'm working > > on fixing the stat struct (probably to blame for files always being > > out of date) and thought I might have it right, I should have known, > > I have it too small and the next variable is getting overwritten, > > causing us to close(0)..> > Yes, the C interfaces are the place where ports are most likely to> be broken. There are no checks there; it's completely unsafe.> I wonder if one could write a checker that compares the sizes of> the most important structures in C and M3, but that would probably> not be trivial.> > > If I put in arbitrary large padding at the end, it grows enough to > > cover up the problem..now to get it right..> > null_fd and the entire struct stat need not be globals, just the dev > > field...of course optimize that and I would have a stack corruption > > instead, not sure it would have been harder or easier to figure > > out..I should have started at the bottom of the system and gotten > > all the headers right in the first place....sigh.> > Yes, it's always a good idea to get the base right at the start.> On the other hand, you will usually return there during ant porting,> regardless of your best efforts ;-)> > > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER;> >> > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > > null_done := TRUE; null_fd := Unix.open( > > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > > and then close 0 here oops IF result # 0 THEN null_fd := -1 END> > [Could you try to persuade your mailer to produce a readable text> form besides HTML? If not it looks like that :-(]> > Anyway, as your previous posting asked about a change in general POSIX> support files, I'd really advise you to try out such changes on at> least one other platform (e.g. Linux), however innocuous they may seem.> > Thanks for all the work,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 17 14:16:59 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 08:16:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> Message-ID: <20080217131659.GA25696@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > [...many other good comments deleted...] > > > >Multiple inheritance was left out of the language after long > >discussions because it was not really understood at that time. > >It may be that things have changed in this respect, but I still > >don't think it is. > > Multiple inheritance is fine so long as it encodes only type, but > *not* if it encodes representation as well. Witness single > inheritance for classes in Java, versus multiple inheritance for > interfaces in Java. That seems to be the general consensus these days. Multiple inheritance could still work under the constraint that no two ancestors provided different representations for any feature. I'd count separate definitions of a virtual function as different even if their code happens to be textually identical. Then an interface (like in Java) would be nothing but a class that has no representation. Then to build a class you could combine little chunks of representation, much as a linker combines little pieces of program. and multiple MODULEs can implement parts of the same INTERFACE. And by combining chunks chunks differently you could build classes with different behaviour. This would make more code-sharing is feasible, without a crisis in semantics. I could consider adding the following clause, because I think it would help modularity (though I'm not sure it's necessary): But if both ancestors have the same defined representation but they are ultimately inherited from the same definition, I'd count them as the same (though I could be argued out of this clause). Actully, I suppose this might be necessary because all objects inherit representation from OBJECT, and a general rule might be better than a special case for OBJECT. -- hendrik From wagner at elegosoft.com Sun Feb 17 14:31:38 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 14:31:38 +0100 Subject: [M3devel] Integration of package-local tests Message-ID: <20080217143138.izfhuwm2yosw0g4w@mail.elegosoft.com> As some of you may have noticed, the regression test scope is increasing steadily though slowly. During recent days I tried to integrate the existing tests that are local to some packages. It's working this way: During a complete package build run with ./scripts/do-cm3-all.sh -report build all pacakges are compiled and the results reported on the web server (see http://www.opencm3.net/logs/package-status.html). For an easy overview, packages that compile OK are coloured green, packages with errors are red, and those unsupported on a certain platform are marked yellow. Recently a fourth column has been added which reports the results of tests if they are present. Tests are assumed if in the package root a sub directory test or tests exists, and if beneath that src/m3makefile is found. The fourth column will be yellow if this is not the case. If tests are present, they are compiled and (probably) run with cm3 -build -override -DROOT=$ROOT -DRUN A sample tests/src/m3makefile from package arithmetic looks like this: import("libm3") import("tempfiles") import("arithmetic") implementation("TestWordEx") implementation("TestBits") %[more test sources omitted] implementation("TestFunctional") Module("Test") program("test") if defined("RUN") r = q_exec( "." & SL & "test" ) write( CR, "program returned ", r, CR ) end The last four lines will run the compiled test executable. Of course, more complex setups are possible there. The test result column will be red if the tests do not compile or another fatal error is detected, orange, if something is output to stderr, and green in all other cases. At least for the actual test candidate an appropriate override should be defined like this: override("arithmetic", PACKAGE_DIR & SL & ".." & SL & "..") As usual, this should be done in the src/m3overrides file. To give a slightly more complex example, the tests for patternmatching are performed thus: if defined("RUN") r = q_exec( "." & SL & "test-regex -unix < .." & SL & "tests.input" ) write( CR, "program returned ", r, CR ) r = q_exec( "." & SL & "test-regex -unix < .." & SL & "testsdiffer.input" ) write( CR, "program returned ", r, CR ) end Here, two test runs are made with different input files. I'd like to encourage all contributors to adapt or extend their packages accordingly, so that more things can be automatically validated every night on miscellaneous platforms. Of course it would also be great if the encountered errors get fixed :-) Thanks for your attention and cooperation, Olaf PS: I'll attach one current package report file for those too lazy to follow the links ;-) PPS: Of course you can run the tests and generate the reports locally, too. During development I've used something like HTML_REPORT=/var/tmp/cm3-pkg-report-FreeBSD4-2008-02-17.html \ time ./scripts/do-cm3-all.sh -report build 2>&1 | tee plog to generate a complete report with a fixed name and log all actions in plog. PPPS: The actual implementation of report generation is in scripts/pkgmap.sh. So you can use -report with almost all build scripts. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sun Feb 17 18:39:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 18:39:07 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> It's now more than two weeks since I asked for participants, and none but the elego tests have shown up in the tinderbox since then. So I think it may be time for a reminder :-) I don't want to hurry anyone, but if anything does not work as expected or described or someone needs help getting tinderbox reports transfered, don't hesitate to contact me. I'd really love to see more platforms than FreeBSD and Linux and the occasional DARWIN tested on a regular basis. Olaf PS: No need to apologize for anyone who maybe hasn't found the time yet to setup the test runs. I really understand that there are many more important matters. Quoting Olaf Wagner : > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression testing >> would help and should be introduced. Tests should be run daily/nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox > /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Sun Feb 17 19:04:44 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 17 Feb 2008 12:04:44 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> References: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Message-ID: <47B8773C.50803@wichita.edu> Well, in the case of pickles, there is not currently any known bit pattern to look for. Everything is either user's data, which must be allowed to be arbitrary, or pickle protocol stuff, which is already written in target-independent ways, so it wouldn't reveal anything. Adding a record of carefully designed, known type and content to the pickle header would work for general machine characteristics, but it's easier just to add a field to RTPacking values, which are binary-encoded in 32 bits in the existing header, with bits to spare. Similarly, for lazy aligned objects (where each type can be different), it's easiest just to add a bit type descriptions, which are also binary encoded. Mika Nystrom wrote: > Hi Rodney, > > I am not sure if I am reading your email entirely correctly, but I > think so... you're trying to figure out things like offsets so the > Pickle runtime can re-build arbitrary data structures. > > When we were doing some concurrent programming in my group about ten > years ago, we were using a user-level threading system (very similar > but not identical to the old user-level threads in M3) and we needed > to figure out the location of the stack pointer in a C jmp_buf. > > We just wrote a program to do it... > > Could you do that? Write some arbitrary data whose bit pattern > you know to a field, cast it to char * (or some such), and search > for the bit pattern? Do it over and over with random data, and there > you go... > > Mika > -- ------------------------------------------------------------- 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 Sun Feb 17 19:03:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 19:03:17 +0100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> I'd rather not go this way and change the complete syntax and convert to and fro between the two. If we really want to do that, I'd rather have it as something like a compatible extension (as far as possible). What about changing only the keywords from uppercase to lowercase and using {} instead of BEGIN END? I'm not sure if that would satisfy the C-adherents, and I'm also not sure if it would introduce syntactic ambiguities, as {} are also used for sets. I'd like to keep the changes to the syntactical structure minimal (upper- and lowercase is only lexical matter after all). The abstract syntax should be kept as it is. If something like this would be possible, I'd vote for supporting both syntaxes in one compiler and turn on the C-style by a comment or automatically by recognizing the first word of a module. I'd not support mixing of styles within one module. Olaf PS: I'm not really suggesting we do this now, I just wanted to comment on the possibility of doing something like this. Anyway it will depend on somebody who provides appropriate patches and updates the language specification etc. Quoting Mika Nystrom : > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; > > And arrays? > > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; > > ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; > > I prefer Algol syntax myself but I could definitely see that there > might be people who would prefer a syntax mapped to C. One might > be able to sneak Modula-3 into places where it wouldn't otherwise > be used... > > Would it be possible to make "m3c" close enough in syntax that some > simple C header files could be processed? Am I just being ridiculous > now? A compiler that can process both C and Modula-3 in the same > file? > > Python, by the way, provides some interesting hooks for C programs > to interact with the Python garbage collector. Something similar > could be done here. (But there is far less reason to write C code > to plug into M3 than there is to write it to plug into Python.) > > Mika > > > Darko writes: >> If you like the idea, maybe you'd like join me in working out what >> such a syntax would look like? Note that I want to keep the structure >> the same, so no assignments in expressions, for example. Also, would C >> programmers revolt at not having post and pre increment, also inside >> expressions (as statements would be ok)? Requiring some sort of EVAL >> statement? I guess the big question is whether removing these things >> would make the whole idea unacceptable to the target audience. Does >> the Algol syntax serve a purpose in making it clear that it isn't C? >> >> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >> >>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>> can figure out how to turn Algol[Modula] back into C using <...>"... >>> >>> If you think it would help acceptance of Modula-3, I don't see why >>> not? >>> >>> I copied the code exactly the way it came off the old half-inch >>> tape from Berkeley. >>> >>> Darko writes: >>>> I'm not sure what you're getting at or if I'm missing something >>>> witty. >>>> I've said the form of the keywords makes little or no difference in >>>> my >>>> opinion. In my mail you quote I say there should be a C like syntax >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>>> matter of taste. I write in both all the time and it doesn't have any >>>> impact on me, I go almost entirely by indentation, which I think is >>>> very important. The indentation is pretty awful in code you posted >>>> but >>>> it could me my mailer. >>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>> ... > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Feb 17 19:11:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 13:11:39 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Not to rain on this parade, but I hate the idea of Swiss-Army-knife programs that do a multitude of tasks. Better to have a program do one thing well (and correctly) than many things badly (incorrectly). So the notion of one compiler handling two syntaxes does not sit well with me. Why not just a preprocessor from C-like syntax, which observes Modula-3 typing and semantics, into regular Modula-3? But, I echo Olaf's point -- there are way more important things to be worrying about than the color of the ceiling tiles, or in this case syntactic sugar. On Feb 17, 2008, at 1:03 PM, Olaf Wagner wrote: > I'd rather not go this way and change the complete syntax and > convert to and fro between the two. If we really want to do that, > I'd rather have it as something like a compatible extension (as far > as possible). > > What about changing only the keywords from uppercase to lowercase > and using {} instead of BEGIN END? I'm not sure if that would > satisfy the C-adherents, and I'm also not sure if it would > introduce syntactic ambiguities, as {} are also used for sets. > I'd like to keep the changes to the syntactical structure minimal > (upper- and lowercase is only lexical matter after all). The abstract > syntax should be kept as it is. > > If something like this would be possible, I'd vote for supporting > both syntaxes in one compiler and turn on the C-style by a comment > or automatically by recognizing the first word of a module. I'd not > support mixing of styles within one module. > > Olaf > > PS: I'm not really suggesting we do this now, I just wanted to comment > on the possibility of doing something like this. Anyway it will > depend on somebody who provides appropriate patches and updates > the language specification etc. > > Quoting Mika Nystrom : > >> Well I used to be mostly a C programmer but I long since weaned >> myself off that syntax :) >> >> Your point of the post- and pre-increment might be a bit difficult >> for C programmers to stomach, but... well it is probably hard to >> tell what programmers will hate and what they will love. >> >> Wouldn't a way to go about it be to take the Modula-3 BNF and modify >> the rules as needed? Would you like to be able to convert back and >> forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case >> all the keywords, convert the braces appropriately (a bit tricky >> since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO >> BEGIN END, so braces map only to the ENDs, not BEGINs (for the most >> part)). >> >> Type "attributes"(is that the right word?) are also an area where >> Modula-3 is significantly different from the C family. In C, you >> write >> >> int *a, *b, c; >> >> we have >> >> REF INTEGER a, b; >> INTEGER c; >> >> And arrays? >> >> VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF >> ARecord; >> >> ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; >> >> I prefer Algol syntax myself but I could definitely see that there >> might be people who would prefer a syntax mapped to C. One might >> be able to sneak Modula-3 into places where it wouldn't otherwise >> be used... >> >> Would it be possible to make "m3c" close enough in syntax that some >> simple C header files could be processed? Am I just being ridiculous >> now? A compiler that can process both C and Modula-3 in the same >> file? >> >> Python, by the way, provides some interesting hooks for C programs >> to interact with the Python garbage collector. Something similar >> could be done here. (But there is far less reason to write C code >> to plug into M3 than there is to write it to plug into Python.) >> >> Mika >> >> >> Darko writes: >>> If you like the idea, maybe you'd like join me in working out what >>> such a syntax would look like? Note that I want to keep the >>> structure >>> the same, so no assignments in expressions, for example. Also, >>> would C >>> programmers revolt at not having post and pre increment, also inside >>> expressions (as statements would be ok)? Requiring some sort of EVAL >>> statement? I guess the big question is whether removing these things >>> would make the whole idea unacceptable to the target audience. Does >>> the Algol syntax serve a purpose in making it clear that it isn't C? >>> >>> >>> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >>> >>>> >>>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>>> can figure out how to turn Algol[Modula] back into C using >>>> <...>"... >>>> >>>> If you think it would help acceptance of Modula-3, I don't see why >>>> not? >>>> >>>> I copied the code exactly the way it came off the old half-inch >>>> tape from Berkeley. >>>> >>>> Darko writes: >>>>> I'm not sure what you're getting at or if I'm missing something >>>>> witty. >>>>> I've said the form of the keywords makes little or no >>>>> difference in >>>>> my >>>>> opinion. In my mail you quote I say there should be a C like >>>>> syntax >>>>> for M3 as well as the existing one. I wasn't being sarcastic. >>>>> It's a >>>>> matter of taste. I write in both all the time and it doesn't >>>>> have any >>>>> impact on me, I go almost entirely by indentation, which I >>>>> think is >>>>> very important. The indentation is pretty awful in code you posted >>>>> but >>>>> it could me my mailer. >>>>> >>>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>>> ... >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Sun Feb 17 19:58:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 13:58:41 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: <20080217185841.GA27354@topoi.pooq.com> On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. Even with a preprocessor from C-style syntax to Modula 3, there would have to be some mechanism inserted into the Modula 3 compiler to recognise the original line numbers for error messages and debuggers and the like. Doing it this way might also make it possible to unify the Eiffel and Modula 3 communities ... though tere are possible better ways to accomplish this. I've always thought there's a lot of duplication of effort in their run-time systems. -- hendrik From lemming at henning-thielemann.de Sun Feb 17 21:27:47 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:27:47 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: On Sun, 17 Feb 2008, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. I see no need for Modula-3 with C syntax. I thought Java was created for this purpose. I collected a long list of C flaws, many of them are due to C syntax. From lemming at henning-thielemann.de Sun Feb 17 21:39:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:39:04 +0100 (MET) Subject: [M3devel] multiple inheritance In-Reply-To: <20080217131659.GA25696@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> <20080217131659.GA25696@topoi.pooq.com> Message-ID: On Sun, 17 Feb 2008 hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > > > [...many other good comments deleted...] > > > > > > >Multiple inheritance was left out of the language after long > > >discussions because it was not really understood at that time. > > >It may be that things have changed in this respect, but I still > > >don't think it is. Without knowing details I have heard that Eiffel has a satisfying implementation of multiple inheritance. However, since programming in Haskell I'm no longer missing traditional object oriented typing at all. From mika at async.caltech.edu Sun Feb 17 22:30:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 13:30:50 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sun, 17 Feb 2008 13:58:41 EST." <20080217185841.GA27354@topoi.pooq.com> Message-ID: <200802172130.m1HLUoMd000557@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: >> Not to rain on this parade, but I hate the idea of Swiss-Army-knife >> programs that do a multitude of tasks. Better to have a program do >> one thing well (and correctly) than many things badly (incorrectly). >> So the notion of one compiler handling two syntaxes does not sit well >> with me. Why not just a preprocessor from C-like syntax, which >> observes Modula-3 typing and semantics, into regular Modula-3? But, >> I echo Olaf's point -- there are way more important things to be >> worrying about than the color of the ceiling tiles, or in this case >> syntactic sugar. > >Even with a preprocessor from C-style syntax to Modula 3, there would >have to be some mechanism inserted into the Modula 3 compiler to >recognise the original line numbers for error messages and debuggers and >the like. > >Doing it this way might also make it possible to unify the Eiffel and >Modula 3 communities ... though tere are possible better ways to >accomplish this. I've always thought there's a lot of duplication of >effort in their run-time systems. > >-- hendrik I agree entirely with Tony's comments. I think a preprocessor (two preprocessors M3-2-MC and MC-2-M3) would be the way to do it, and I really don't mind Algol syntax. But I can see the argument that it might really do something for "marketing". I believe the compiler already permits <* LINE *> pragmas?? I think I saw it in the caltech-parser? Also if you want to merge forces with another project, wouldn't a good way be to do as in Stallman's nightmares, and start by "selling" the compiler back ends to other languages? Mika From jayk123 at hotmail.com Mon Feb 18 05:03:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:03:23 +0000 Subject: [M3devel] instructions for how to bring up a working NT386GNU toolset today Message-ID: This email has whitespace at the start/end of most lines in an attempt to preserve its formating. I already had cm3cg, and it is slow to rebuild. These instructions omit building that, but it is just build and ship in m3-sys\m3cc. Building m3cc does require a fair bit of Cygwin installed. Including but not limited to gcc, binutils, sed, make, awk. copy \cm3\bin\cm3cg.exe C:\cm3-min-WIN32-NT386-5.1.8\bin rmdir /q/s \cm3 xcopy /fivery C:\cm3-min-WIN32-NT386-5.1.8 c:\cm3 Older than 5.1.8 will not work. Setup a cm3/NT386 build environment, for example: set CM3_GCC_BACKEND=no set CM3_INSTALL=c:\cm3 set CM3_OSTYPE=WIN32 set CM3_ROOT=c:\dev2\cm3.2 set CM3_TARGET=NT386 set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 Almost none of these are needed, as they are probed for quite successfully. However this is what I am testing right now. Make sure Cygwin link.exe is not in %PATH%. I just delete it. del \cygwin\bin\link.exe I do actually have Cygwin always on my path, so there might be hidden dependencies on that. type \AUTOEXEC.BAT set CVS_RSH=ssh PATH %SystemDrive%\cygwin\bin;%PATH% There are also presently problems with slashes, such that managing M3CONFIG manually is a good idea for now. cd /d %cm3_root%\scripts\python .\do-cm3-all.py realclean .\upgrade.py In another cmd window, setup a CM3/NT386GNU environment, for example: set CM3_GCC_BACKEND=yes set CM3_INSTALL=/cm3 set CM3_OSTYPE=POSIX set CM3_ROOT=/dev2/cm3.2 set CM3_TARGET=NT386 set M3CONFIG=/dev2/cm3.2/m3-sys/cminstall/src/config/NT386GNU set OMIT_GCC=yes Again, this is largely redundant, but ok. What is most important is that CM3_OSTYPE=POSIX or that Cygwin uname is in the path. (Work is needed to cleanup this area that I have muddied over the past few months, including teaching cm3 that forward slashes work on Win32, except that won't help bootstrapping from 5.1.8) Also NOTE that I have symlinks setup for these paths to be correct: ls -l / lrwxrwxrwx 1 Jay None 11 Feb 10 01:10 c -> /cygdrive/c lrwxrwxrwx 1 Jay None 6 Feb 10 21:39 cm3 -> /c/cm3 lrwxrwxrwx 1 Jay None 7 Feb 10 01:10 dev2 -> /c/dev2 /cygdrive is long and ugly. .\do-cm3-all.py realclean Back in the NT386 environment: Point at the NT386GNU configuration file: set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386GNU Build the minimum NT386GNU system using the NT386 host compiler: .\bootntgnu.py and then restore the configuration to "normal": set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 (Yeah yeah, to clean step should work here.) Back in the NT386GNU environment: .\install-cm3-compiler.py .\upgrade.py Done. Next step is to try make-dist.py. (It doesn't work.) Also note that do-cm3-std gets much further than these steps. But these are just to start and get your own "min" system. A crash in m3bundle needs investigation if is still happens. Lots of GUI stuff does build but I haven't tried running it yet. Also NOTE that the integrated backend should be viable for targeting the Cygwin runtime, and this will build MUCH faster. Of course, you must have current source for this to work. I have not yet run the tests, sorry Olaf. Anyone want to try this and report back how it goes? Please? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx From hosking at cs.purdue.edu Mon Feb 18 05:16:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 23:16:06 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> Message-ID: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Solaris does not have %s for date -- we need an alternative for that usage in tinderbox-build.sh. On Feb 17, 2008, at 12:39 PM, Olaf Wagner wrote: > It's now more than two weeks since I asked for participants, and > none but the elego tests have shown up in the tinderbox since then. > So I think it may be time for a reminder :-) > > I don't want to hurry anyone, but if anything does not work as > expected or described or someone needs help getting tinderbox > reports transfered, don't hesitate to contact me. I'd really love to > see more platforms than FreeBSD and Linux and the occasional DARWIN > tested on a regular basis. > > Olaf > > PS: No need to apologize for anyone who maybe hasn't found the time > yet > to setup the test runs. I really understand that there are many > more > important matters. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >>> o I think we have agreed on the fact that automatic regression >>> testing >>> would help and should be introduced. Tests should be run daily/ >>> nightly >>> on as many platforms as possible, and results should be collected >>> and made available via WWW (elego offers to host these >>> services, as >>> it does for CVS repositories and CM3 web access). >> >> As you've surely all seen in the Status section of >> >> http://modula3.elegosoft.com/cm3/ >> >> the Elego Tinderbox regression test framework for CM3 has now been >> working for about two weeks. Though it's still not as complete and >> stable as I'd like it to be, I think it is now the right time for >> others >> to join the test framework and run the prepared tests in regular >> intervals on their favourite platforms. The results can now be >> transfered >> to Elego via your ssh account you also use for repository commits. >> >> Currently the tests are running on a Debian Linux system and a >> FreeBSD 6 >> system at Elego, and now and then I'm starting a run on my MacOS X >> laptop. The latter is not ideal for this purpose though. >> >> I'm now looking for other who would be willing to setup nightly tests >> on their own servers. The following systems are of interest >> >> o PPC_DARWIN on MacOS X 10.4 or 10.5 >> o I386_DARWIN >> o SOLgnu on any Solaris version >> o SOLsun " >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten >> some variants?) >> o NT386* on Windows 2000/XP/Vista >> o NetBSD2_i386 >> o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) >> o PPC_LINUX (though this seems to be broken for some time) >> o ALPHA_OSF -- is anybody still using Alphas? >> >> I think the other targets are more or less unused, but would of >> course not >> object to test results for them. >> >> There's a short description by Kaspar Schleiser of how to >> participate in >> cm3/scripts/regression/README. Basically you need to checkout the >> scripts, install 5.4.0 manually once, and setup a cron job. >> >> We're mostly interested in the results of `tinderbox-build.sh >> cm3.build', >> which is the complete bootstrap and release build based on 5.4.0, >> as I think the lastok build need not run on all platforms. It's >> mainly >> there to detect incompatible changes. >> >> The release build includes the package and m3tests tests. >> >> If you want to participate, I'd suggest to setup everything and run >> it once without transferring your results, then enable the transfer >> in cm3.build: >> >> tinderbox_mailer() { >> true # needed if function is emtpy without this... >> # to report to the elego tinderbox host, check README and >> uncomment this: >> # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox >> /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" >> } >> >> That's all. Please let me know in advance if you setup the tests, >> >> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Mon Feb 18 05:26:17 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:26:17 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3. Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal. Compatibility with headers is problematic but very useful. This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language. It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > I'd rather not go this way and change the complete syntax and> convert to and fro between the two. If we really want to do that,> I'd rather have it as something like a compatible extension (as far> as possible).> > What about changing only the keywords from uppercase to lowercase> and using {} instead of BEGIN END? I'm not sure if that would> satisfy the C-adherents, and I'm also not sure if it would> introduce syntactic ambiguities, as {} are also used for sets.> I'd like to keep the changes to the syntactical structure minimal> (upper- and lowercase is only lexical matter after all). The abstract> syntax should be kept as it is.> > If something like this would be possible, I'd vote for supporting> both syntaxes in one compiler and turn on the C-style by a comment> or automatically by recognizing the first word of a module. I'd not> support mixing of styles within one module.> > Olaf> > PS: I'm not really suggesting we do this now, I just wanted to comment> on the possibility of doing something like this. Anyway it will> depend on somebody who provides appropriate patches and updates> the language specification etc.> > Quoting Mika Nystrom :> > > Well I used to be mostly a C programmer but I long since weaned> > myself off that syntax :)> >> > Your point of the post- and pre-increment might be a bit difficult> > for C programmers to stomach, but... well it is probably hard to> > tell what programmers will hate and what they will love.> >> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify> > the rules as needed? Would you like to be able to convert back and> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case> > all the keywords, convert the braces appropriately (a bit tricky> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most> > part)).> >> > Type "attributes"(is that the right word?) are also an area where> > Modula-3 is significantly different from the C family. In C, you> > write> >> > int *a, *b, c;> >> > we have> >> > REF INTEGER a, b;> > INTEGER c;> >> > And arrays?> >> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;> >> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];> >> > I prefer Algol syntax myself but I could definitely see that there> > might be people who would prefer a syntax mapped to C. One might> > be able to sneak Modula-3 into places where it wouldn't otherwise> > be used...> >> > Would it be possible to make "m3c" close enough in syntax that some> > simple C header files could be processed? Am I just being ridiculous> > now? A compiler that can process both C and Modula-3 in the same> > file?> >> > Python, by the way, provides some interesting hooks for C programs> > to interact with the Python garbage collector. Something similar> > could be done here. (But there is far less reason to write C code> > to plug into M3 than there is to write it to plug into Python.)> >> > Mika> >> >> > Darko writes:> >> If you like the idea, maybe you'd like join me in working out what> >> such a syntax would look like? Note that I want to keep the structure> >> the same, so no assignments in expressions, for example. Also, would C> >> programmers revolt at not having post and pre increment, also inside> >> expressions (as statements would be ok)? Requiring some sort of EVAL> >> statement? I guess the big question is whether removing these things> >> would make the whole idea unacceptable to the target audience. Does> >> the Algol syntax serve a purpose in making it clear that it isn't C?> >>> >>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:> >>> >>>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you> >>> can figure out how to turn Algol[Modula] back into C using <...>"...> >>>> >>> If you think it would help acceptance of Modula-3, I don't see why> >>> not?> >>>> >>> I copied the code exactly the way it came off the old half-inch> >>> tape from Berkeley.> >>>> >>> Darko writes:> >>>> I'm not sure what you're getting at or if I'm missing something> >>>> witty.> >>>> I've said the form of the keywords makes little or no difference in> >>>> my> >>>> opinion. In my mail you quote I say there should be a C like syntax> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a> >>>> matter of taste. I write in both all the time and it doesn't have any> >>>> impact on me, I go almost entirely by indentation, which I think is> >>>> very important. The indentation is pretty awful in code you posted> >>>> but> >>>> it could me my mailer.> >>>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:> >>> ...> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 18 05:41:29 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 20:41:29 -0800 Subject: [M3devel] code submission Message-ID: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> Hello everyone, I was looking at some code I've written and realized that I have a very small piece of tested code that may be of interest to other Modula-3 users. It's a generic "trie" that I coded a few years ago. Does anyone have an opinion on adding it to cm3? Where, if so? http://www.async.caltech.edu/~mika/trie/ It's useful for parsing; if you're parsing a language with longish keywords it is many times faster to use this structure and ARRAY OF CHAR than using the standard hash tables with TEXTs. (I developed it to parse an old "punch-card", i.e., 80-character fixed-width records, format for financial data.) Mika From wagner at elegosoft.com Mon Feb 18 08:32:39 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 08:32:39 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Message-ID: <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> Quoting Tony Hosking : > Solaris does not have %s for date -- we need an alternative for that > usage in tinderbox-build.sh. You mean as in date -u +'%Y-%m-%d-%H-%M-%S? It's used quite often: % grep -l date scripts/regression/*.sh scripts/regression/defs.sh scripts/regression/tinderbox-build.sh scripts/regression/tinderbox-status.sh scripts/regression/update_changelog.sh scripts/regression/update_m3tests.sh scripts/regression/update_pkg_status.sh scripts/regression/update_snapshot_status.sh Would it be possible, as a work-around, to install the GNU tools (date, sed, awk etc.)? I should have known something will fail on Solaris, because the standard command line utilities they ship are still bug-compatible to those from the 80s :-/ We've had lots of problems with them at one of our customers, too, and just installed openpkg as a stable environment. But I think GNU command line utilties should also be available as a Solaris package. If this is the only problem or if you cannot install an alternative environment, we'll have to do something about date. I'll make some tests later when I have access to a SPARC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 10:20:29 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 09:20:29 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Some corrections.. try to make braces work (with some alteration for C) >> for SETS Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "but" should say "punt" That is, this dialect of C that has some Modula-3 features, might have optional safety, or even garbage collection. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]Date: Mon, 18 Feb 2008 04:26:17 +0000 I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3.Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal.Compatibility with headers is problematic but very useful.This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language.It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > I'd rather not go this way and change the complete syntax and> convert to and fro between the two. If we really want to do that,> I'd rather have it as something like a compatible extension (as far> as possible).> > What about changing only the keywords from uppercase to lowercase> and using {} instead of BEGIN END? I'm not sure if that would> satisfy the C-adherents, and I'm also not sure if it would> introduce syntactic ambiguities, as {} are also used for sets.> I'd like to keep the changes to the syntactical structure minimal> (upper- and lowercase is only lexical matter after all). The abstract> syntax should be kept as it is.> > If something like this would be possible, I'd vote for supporting> both syntaxes in one compiler and turn on the C-style by a comment> or automatically by recognizing the first word of a module. I'd not> support mixing of styles within one module.> > Olaf> > PS: I'm not really suggesting we do this now, I just wanted to comment> on the possibility of doing something like this. Anyway it will> depend on somebody who provides appropriate patches and updates> the language specification etc.> > Quoting Mika Nystrom :> > > Well I used to be mostly a C programmer but I long since weaned> > myself off that syntax :)> >> > Your point of the post- and pre-increment might be a bit difficult> > for C programmers to stomach, but... well it is probably hard to> > tell what programmers will hate and what they will love.> >> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify> > the rules as needed? Would you like to be able to convert back and> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case> > all the keywords, convert the braces appropriately (a bit tricky> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most> > part)).> >> > Type "attributes"(is that the right word?) are also an area where> > Modula-3 is significantly different from the C family. In C, you> > write> >> > int *a, *b, c;> >> > we have> >> > REF INTEGER a, b;> > INTEGER c;> >> > And arrays?> >> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;> >> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];> >> > I prefer Algol syntax myself but I could definitely see that there> > might be people who would prefer a syntax mapped to C. One might> > be able to sneak Modula-3 into places where it wouldn't otherwise> > be used...> >> > Would it be possible to make "m3c" close enough in syntax that some> > simple C header files could be processed? Am I just being ridiculous> > now? A compiler that can process both C and Modula-3 in the same> > file?> >> > Python, by the way, provides some interesting hooks for C programs> > to interact with the Python garbage collector. Something similar> > could be done here. (But there is far less reason to write C code> > to plug into M3 than there is to write it to plug into Python.)> >> > Mika> >> >> > Darko writes:> >> If you like the idea, maybe you'd like join me in working out what> >> such a syntax would look like? Note that I want to keep the structure> >> the same, so no assignments in expressions, for example. Also, would C> >> programmers revolt at not having post and pre increment, also inside> >> expressions (as statements would be ok)? Requiring some sort of EVAL> >> statement? I guess the big question is whether removing these things> >> would make the whole idea unacceptable to the target audience. Does> >> the Algol syntax serve a purpose in making it clear that it isn't C?> >>> >>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:> >>> >>>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you> >>> can figure out how to turn Algol[Modula] back into C using <...>"...> >>>> >>> If you think it would help acceptance of Modula-3, I don't see why> >>> not?> >>>> >>> I copied the code exactly the way it came off the old half-inch> >>> tape from Berkeley.> >>>> >>> Darko writes:> >>>> I'm not sure what you're getting at or if I'm missing something> >>>> witty.> >>>> I've said the form of the keywords makes little or no difference in> >>>> my> >>>> opinion. In my mail you quote I say there should be a C like syntax> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a> >>>> matter of taste. I write in both all the time and it doesn't have any> >>>> impact on me, I go almost entirely by indentation, which I think is> >>>> very important. The indentation is pretty awful in code you posted> >>>> but> >>>> it could me my mailer.> >>>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:> >>> ...> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 18 11:34:34 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 11:34:34 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Message-ID: <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Quoting Tony Hosking : > Solaris does not have %s for date -- we need an alternative for that > usage in tinderbox-build.sh. You're probably talking about a different problem than I thought, at least % date -u +'%Y-%m-%d-%H-%M-%S' 2008-02-18-10-00-34 blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % type date date is hashed (/bin/date) blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % uname -a SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 seems to be working for me on Solaris. Ah, I've found it now: date +%s. Michael says it's not possible to do that with Sun's data. Openpkg for example comes with gdate, which understands the %s: % gdate "+%s" 1203329509 blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % type gdate gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) gdate is part of the GNU coreutils. You can find it at http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml http://www.sunfreeware.com/programlistsparc10.html#coreutils Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Mon Feb 18 12:45:25 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Mon, 18 Feb 2008 12:45:25 +0100 Subject: [M3devel] List test Message-ID: <20080218124525.ego4vs4x4ok0gkko@mail.elegosoft.com> Please ignore. -- 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 hosking at cs.purdue.edu Mon Feb 18 14:39:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 08:39:23 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> Message-ID: No, I mean date '+%s', which just gives a raw time-stamp. date -u +'% Y-%m-%d-%H-%M-%S works just fine. I don't manage this machine so I'd like to avoid installing non- standard tools (if only so they don't get tangled up in the regression testing which should be done on a "vanilla" platform). On Feb 18, 2008, at 2:32 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Solaris does not have %s for date -- we need an alternative for that >> usage in tinderbox-build.sh. > > You mean as in date -u +'%Y-%m-%d-%H-%M-%S? > > It's used quite often: > % grep -l date scripts/regression/*.sh > scripts/regression/defs.sh > scripts/regression/tinderbox-build.sh > scripts/regression/tinderbox-status.sh > scripts/regression/update_changelog.sh > scripts/regression/update_m3tests.sh > scripts/regression/update_pkg_status.sh > scripts/regression/update_snapshot_status.sh > > Would it be possible, as a work-around, to install the GNU tools > (date, sed, awk etc.)? > > I should have known something will fail on Solaris, because the > standard command line utilities they ship are still bug-compatible > to those from the 80s :-/ We've had lots of problems with them > at one of our customers, too, and just installed openpkg as a stable > environment. But I think GNU command line utilties should also > be available as a Solaris package. > > If this is the only problem or if you cannot install an alternative > environment, we'll have to do something about date. I'll make some > tests later when I have access to a SPARC. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 14:41:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 08:41:49 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Message-ID: Yeah, perhaps I should install gdate. On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Solaris does not have %s for date -- we need an alternative for that >> usage in tinderbox-build.sh. > > You're probably talking about a different problem than I thought, > at least > > % date -u +'%Y-%m-%d-%H-%M-%S' > 2008-02-18-10-00-34 > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % type date > date is hashed (/bin/date) > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % uname -a > SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 > > seems to be working for me on Solaris. > > Ah, I've found it now: date +%s. > Michael says it's not possible to do that with Sun's data. > Openpkg for example comes with gdate, which understands the %s: > > % gdate "+%s" > 1203329509 > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % type gdate > gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) > > gdate is part of the GNU coreutils. You can find it at > > http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml > > http://www.sunfreeware.com/programlistsparc10.html#coreutils > > Hope this helps, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 15:02:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 15:02:22 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Message-ID: <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> Quoting Tony Hosking : > Yeah, perhaps I should install gdate. Is that acceptable then, or would you prefer that we write a small program (in C or M3) which only prints the seconds since the start of the epoch for the sake of tinderbox? Olaf > On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> Solaris does not have %s for date -- we need an alternative for that >>> usage in tinderbox-build.sh. >> >> You're probably talking about a different problem than I thought, >> at least >> >> % date -u +'%Y-%m-%d-%H-%M-%S' >> 2008-02-18-10-00-34 >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % type date >> date is hashed (/bin/date) >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % uname -a >> SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 >> >> seems to be working for me on Solaris. >> >> Ah, I've found it now: date +%s. >> Michael says it's not possible to do that with Sun's data. >> Openpkg for example comes with gdate, which understands the %s: >> >> % gdate "+%s" >> 1203329509 >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % type gdate >> gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) >> >> gdate is part of the GNU coreutils. You can find it at >> >> http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml >> >> http://www.sunfreeware.com/programlistsparc10.html#coreutils >> >> Hope this helps, >> >> Olaf >> -- Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Feb 18 15:19:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 09:19:55 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> Message-ID: <2BF46AA7-9BCA-4FFC-AE59-76707FFCC037@cs.purdue.edu> Yes, acceptable. I'll install gdate. On Feb 18, 2008, at 9:02 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Yeah, perhaps I should install gdate. > > Is that acceptable then, or would you prefer that we write a > small program (in C or M3) which only prints the seconds since the > start of the epoch for the sake of tinderbox? > > Olaf > >> On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> Solaris does not have %s for date -- we need an alternative for >>>> that >>>> usage in tinderbox-build.sh. >>> >>> You're probably talking about a different problem than I thought, >>> at least >>> >>> % date -u +'%Y-%m-%d-%H-%M-%S' >>> 2008-02-18-10-00-34 >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % type date >>> date is hashed (/bin/date) >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % uname -a >>> SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 >>> >>> seems to be working for me on Solaris. >>> >>> Ah, I've found it now: date +%s. >>> Michael says it's not possible to do that with Sun's data. >>> Openpkg for example comes with gdate, which understands the %s: >>> >>> % gdate "+%s" >>> 1203329509 >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % type gdate >>> gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) >>> >>> gdate is part of the GNU coreutils. You can find it at >>> >>> http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml >>> >>> http://www.sunfreeware.com/programlistsparc10.html#coreutils >>> >>> Hope this helps, >>> >>> Olaf >>> -- Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Mon Feb 18 16:56:20 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 18 Feb 2008 10:56:20 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B60CE0.8050506@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> Message-ID: <47B9644F.1E75.00D7.1@scires.com> I use pickles extensively and they are used also by network objects. I've never used LAZYALIGN. My vote is that we don't break something (pickles/netobj) to add support for something that is rarely used. Regards, Randy >>> "Rodney M. Bates" 2/15/2008 5:06 PM >>> I'll put it in comments in the code. I am sure I can fix it to handle LAZYALIGN too, just not sure whether I can do it without requiring existing pickle files to be regenerated and/or existing code that reads/writes pickles to need recompilation. Anybody on this list who has code that might be affected if pickles or compiled code were invalidated by a change? I do propose we change the way of telling the compiler to do LAZYALIGN so that it is a property of a type and affects all variables of that type. Olaf Wagner wrote: > Perhaps we should check-in this description somewhere near the > actual code? Or is there enough documentation already? > > Olaf > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > Or at least put a big sticker on that it will break pickles. > > Quoting "Rodney M. Bates" : > >> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >> etc. only works for getting object layouts as on the machine executing >> the code, which is all that is needed when writing a pickle. >> >> When reading, Pickle code needs to know the layouts of a type both as >> it is on the reading machine and as it was on the machine that wrote >> the pickle. The type description that the compiler generates is >> excerpted and contains no field displacements, just lists of field >> types (which are either recursive type descriptions or builtin types). >> So it is independent of word sizes, etc. >> >> Pickles regenerates the displacements using the few target machine >> characteristics in a RTPacking.T It traverses a type description and >> simultaneously computes two sets of field displacements, both as they >> are on the reading machine and on the writing machine. For the latter, >> the value of RTPacking.T is (after a compact bit encoding) stored in the >> header of the pickle file. For the former, it's gotten by techniques >> like >> using BITSIZE. This is actually all done in RTTipe, part of m3core, and >> called by Pickle code. >> >> This is very fragile. RTTipe has to duplicate the compiler's layout >> behavior. There is no shared code. Making it common would involve >> quite a bit of rework, as the two use substantially different data >> structure and code organization. It will be obvious what kind of bit >> damage could occur if the two algorithms didn't agree. >> >> This is why I am obsessing over LAZYALIGN. I have been comparing the >> field displacement computations in RTTipe and in the compiler. The >> former is oblivious to LAZYALIGN. >> >> Note that all this is required even without any packing of small fields >> within words. E.G., a record with two INTEGER fields, pickled on a >> 32-bit machine and unpickled on a 64. >> >> Tony Hosking wrote: >> >>> Rodney, >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> would have thought all packing is done on word-sized units anyway. >>> Each side of the connection can check BITSIZE(LONGINT) to figure >>> out what to do presumably no differently from the way INTEGER is >>> communicated between 32-bit and 64-bit machines. Am I missing >>> something? >>> >>> -- Tony >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> (which can vary independently of the size of INTEGER). >>>>> 2) Variable length values of subrange bounds found in type >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> what the native word size can represent. >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>>> is not handled by Pickles. >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> >>> >> >> -- >> ------------------------------------------------------------- >> 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 > > > > -- ------------------------------------------------------------- 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 Mon Feb 18 18:36:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 12:36:43 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B9644F.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> Message-ID: <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Can someone remind me again why we need LAZYALIGN? I concur with Randy that if it is rarely used and moreso breaks things I would argue to abandon it. On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add > support for something that is rarely used. > Regards, > Randy > > >>> "Rodney M. Bates" 2/15/2008 5:06 PM >>> > I'll put it in comments in the code. I am sure I can fix it to > handle LAZYALIGN too, just not sure whether I can do it without > requiring existing pickle files to be regenerated and/or existing > code that reads/writes pickles to need recompilation. > > Anybody on this list who has code that might be affected if pickles > or compiled code were invalidated by a change? > > I do propose we change the way of telling the compiler to do > LAZYALIGN so that it is a property of a type and affects all > variables of that type. > > Olaf Wagner wrote: > > Perhaps we should check-in this description somewhere near the > > actual code? Or is there enough documentation already? > > > > Olaf > > > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > > Or at least put a big sticker on that it will break pickles. > > > > Quoting "Rodney M. Bates" : > > > >> The word "Packing" in RTPacking is perhaps misleading. Using > BITSIZE, > >> etc. only works for getting object layouts as on the machine > executing > >> the code, which is all that is needed when writing a pickle. > >> > >> When reading, Pickle code needs to know the layouts of a type > both as > >> it is on the reading machine and as it was on the machine that > wrote > >> the pickle. The type description that the compiler generates is > >> excerpted and contains no field displacements, just lists of field > >> types (which are either recursive type descriptions or builtin > types). > >> So it is independent of word sizes, etc. > >> > >> Pickles regenerates the displacements using the few target machine > >> characteristics in a RTPacking.T It traverses a type > description and > >> simultaneously computes two sets of field displacements, both as > they > >> are on the reading machine and on the writing machine. For the > latter, > >> the value of RTPacking.T is (after a compact bit encoding) > stored in the > >> header of the pickle file. For the former, it's gotten by > techniques > >> like > >> using BITSIZE. This is actually all done in RTTipe, part of > m3core, and > >> called by Pickle code. > >> > >> This is very fragile. RTTipe has to duplicate the compiler's > layout > >> behavior. There is no shared code. Making it common would involve > >> quite a bit of rework, as the two use substantially different data > >> structure and code organization. It will be obvious what kind > of bit > >> damage could occur if the two algorithms didn't agree. > >> > >> This is why I am obsessing over LAZYALIGN. I have been > comparing the > >> field displacement computations in RTTipe and in the compiler. The > >> former is oblivious to LAZYALIGN. > >> > >> Note that all this is required even without any packing of small > fields > >> within words. E.G., a record with two INTEGER fields, pickled on a > >> 32-bit machine and unpickled on a 64. > >> > >> Tony Hosking wrote: > >> > >>> Rodney, > >>> > >>> Why does there need to be an entry for LONGINT in RTPacking? I > >>> would have thought all packing is done on word-sized units > anyway. > >>> Each side of the connection can check BITSIZE(LONGINT) to figure > >>> out what to do presumably no differently from the way INTEGER is > >>> communicated between 32-bit and 64-bit machines. Am I missing > >>> something? > >>> > >>> -- Tony > >>> > >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >>> > >>>> Ah, OK. I don't much delve in pickle-land. Anything I can > help with? > >>>> > >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >>>> > >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, > >>>>> (which can vary independently of the size of INTEGER). > >>>>> 2) Variable length values of subrange bounds found in type > >>>>> descriptions (in TipeDesc.i3) can now have values beyond > >>>>> what the native word size can represent. > >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added > recently) > >>>>> is not handled by Pickles. > >>>>> > >>>>> I have done some coding on this, but have been interrupted. > >>>>> > >>>>> Tony Hosking wrote: > >>>>> > >>>>>> Why is LONGINT for pickles not yet supported? > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> ------------------------------------------------------------- > >>>>> 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 > >>> > >>> > >>> > >>> > >> > >> -- > >> ------------------------------------------------------------- > >> 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 > > > > > > > > > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Mon Feb 18 19:55:53 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 10:55:53 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 18 Feb 2008 16:16:44." <20080218151644.E5E4410D4331@birch.elegosoft.com> Message-ID: <200802181855.m1IItr0w032707@camembert.async.caltech.edu> Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 08/02/18 16:16:44 > >Modified files: > cm3/m3-sys/m3quake/src/: QMachine.i3 QMachine.m3 > cm3/m3-sys/cm3/src/: M3Path.m3 > >Log message: > At least for purposes of determining if Join(a,b) is b or a + slash + b, > treat any path that starts with a forward or backward slash, or > contains a colon as the second character, as absolute, on all platforms. > It is ASSUMED that backslashes and colons are never used in paths > on non-Windows systems, or at least that this interpretation is ok. I think people are careful not to use backslashes on Unix because it does weird things in the shell, so "it's not surprising" if things go bad if you use backslashes in your filenames. I know I never have, on purpose. But colons? Colons are not special in any way, shape, or form, on Unix... I think "it is extremely surprising" to a Unix user if a path with a colon in it breaks something. Mika From wagner at elegosoft.com Mon Feb 18 20:35:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 20:35:36 +0100 Subject: [M3devel] code submission In-Reply-To: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> References: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> Message-ID: <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> Quoting Mika Nystrom : > Hello everyone, > > I was looking at some code I've written and realized that I have a > very small piece of tested code that may be of interest to other > Modula-3 users. It's a generic "trie" that I coded a few years > ago. Does anyone have an opinion on adding it to cm3? Where, if so? > > http://www.async.caltech.edu/~mika/trie/ > > It's useful for parsing; if you're parsing a language with longish > keywords it is many times faster to use this structure and ARRAY > OF CHAR than using the standard hash tables with TEXTs. (I developed > it to parse an old "punch-card", i.e., 80-character fixed-width > records, format for financial data.) Of course we could add this as a small package to m3-libs, or even to libm3 (it looks rather small). I hate to sound so uneducated, but what exactly does `trie' stand for? It's not contained in my favourite online dictionary either. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 20:37:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 19:37:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802181855.m1IItr0w032707@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 16:16:44." <20080218151644.E5E4410D4331@birch.elegosoft.com> <200802181855.m1IItr0w032707@camembert.async.caltech.edu> Message-ID: > But colons? Colons are not special in any way, shape, or form, on> Unix... I think "it is extremely surprising" to a Unix user if a path Ever try putting a path with a colon into $PATH? Does it work? Or copying a file with a colon in its name to a Windows system? Does it work? This part could be limited to systems that have $OS == Windows_NT I guess. As a user switching between multiple systems, this area is quite frustrating...I guess no matter what. Sometimes one form works, sometimes another, sometimes either, often with identical meaning, but not always. These changes, and about one more, should make building NT386GNU a fair amount easier.. Currently it is any path with a colon in the second character. How about if that is further restricted to having a-z in the first character and/or more importantly a slash in the third character? - Jay > To: jkrell at elego.de> Date: Mon, 18 Feb 2008 10:55:53 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay Krell writes:> >CVSROOT: /usr/cvs> >Changes by: jkrell at birch. 08/02/18 16:16:44> >> >Modified files:> > cm3/m3-sys/m3quake/src/: QMachine.i3 QMachine.m3 > > cm3/m3-sys/cm3/src/: M3Path.m3 > >> >Log message:> > At least for purposes of determining if Join(a,b) is b or a + slash + b,> > treat any path that starts with a forward or backward slash, or> > contains a colon as the second character, as absolute, on all platforms.> > It is ASSUMED that backslashes and colons are never used in paths> > on non-Windows systems, or at least that this interpretation is ok.> > I think people are careful not to use backslashes on Unix because> it does weird things in the shell, so "it's not surprising" if> things go bad if you use backslashes in your filenames. I know I> never have, on purpose.> > But colons? Colons are not special in any way, shape, or form, on> Unix... I think "it is extremely surprising" to a Unix user if a path> with a colon in it breaks something. > > Mika _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 18 20:50:20 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 19:50:20 +0000 Subject: [M3devel] code submission In-Reply-To: <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> References: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> Message-ID: aka "prefix tree" if I want to recognize the strings, foo, food, fudge, and bar look at the first character if it is 'b', go ahead and compare to bar (or the tail to "ar") if it is 'f' look at the second character if it is 'u', go ahead and compare to "fudge" (or the tail to "dge") if it 'o' compare the third character and so on Whether or not the data "stops" at unique prefixes is an implementation detail. If it does, the leaves can contain the entire string or just the tail. I've fiddled with generating large nested switch statements from a list of strings. I noticed there are many optimizations you can make. Of course, first you check the length. Then, really, instead of progressing from left to right, you can pick out characters with a higher switching factor. For example if I have the strings foof and food, just look at the last character. As well a hash based algorithm is probably best. Precompute the hashes of all the strings. Sor them. Hash your input string. Binary search for the hash. And the compare for an exact match. If you are going to do the final compare anyway, then you are going to touch the whole string anyway, you might as well hash it and do a binary search I think. Make sure the hash function is fast of course, and not "perfect". - Jay > Date: Mon, 18 Feb 2008 20:35:36 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] code submission> > Quoting Mika Nystrom :> > > Hello everyone,> >> > I was looking at some code I've written and realized that I have a> > very small piece of tested code that may be of interest to other> > Modula-3 users. It's a generic "trie" that I coded a few years> > ago. Does anyone have an opinion on adding it to cm3? Where, if so?> >> > http://www.async.caltech.edu/~mika/trie/> >> > It's useful for parsing; if you're parsing a language with longish> > keywords it is many times faster to use this structure and ARRAY> > OF CHAR than using the standard hash tables with TEXTs. (I developed> > it to parse an old "punch-card", i.e., 80-character fixed-width> > records, format for financial data.)> > Of course we could add this as a small package to m3-libs, or> even to libm3 (it looks rather small).> > I hate to sound so uneducated, but what exactly does `trie' stand for?> It's not contained in my favourite online dictionary either.> > Olaf> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Feb 18 21:01:39 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 07:01:39 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: The alignment behaviour is absolutely crucial to programming natively in Mac OS X and should be kept. I have a great need for it. The PRGAMA is of no use and can be removed. Does anyone have any objections to making this alignment behaviour standard? On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > Can someone remind me again why we need LAZYALIGN? I concur with > Randy that if it is rarely used and moreso breaks things I would > argue to abandon it. > > On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > >> I use pickles extensively and they are used also by network objects. >> I've never used LAZYALIGN. >> My vote is that we don't break something (pickles/netobj) to add >> support for something that is rarely used. >> Regards, >> Randy >> >> >>> "Rodney M. Bates" 2/15/2008 5:06 PM >> >>> >> I'll put it in comments in the code. I am sure I can fix it to >> handle LAZYALIGN too, just not sure whether I can do it without >> requiring existing pickle files to be regenerated and/or existing >> code that reads/writes pickles to need recompilation. >> >> Anybody on this list who has code that might be affected if pickles >> or compiled code were invalidated by a change? >> >> I do propose we change the way of telling the compiler to do >> LAZYALIGN so that it is a property of a type and affects all >> variables of that type. >> >> Olaf Wagner wrote: >> > Perhaps we should check-in this description somewhere near the >> > actual code? Or is there enough documentation already? >> > >> > Olaf >> > >> > PS: Based on your description, I'd say we should abandon LAZYALIGN. >> > Or at least put a big sticker on that it will break pickles. >> > >> > Quoting "Rodney M. Bates" : >> > >> >> The word "Packing" in RTPacking is perhaps misleading. Using >> BITSIZE, >> >> etc. only works for getting object layouts as on the machine >> executing >> >> the code, which is all that is needed when writing a pickle. >> >> >> >> When reading, Pickle code needs to know the layouts of a type >> both as >> >> it is on the reading machine and as it was on the machine that >> wrote >> >> the pickle. The type description that the compiler generates is >> >> excerpted and contains no field displacements, just lists of field >> >> types (which are either recursive type descriptions or builtin >> types). >> >> So it is independent of word sizes, etc. >> >> >> >> Pickles regenerates the displacements using the few target machine >> >> characteristics in a RTPacking.T It traverses a type >> description and >> >> simultaneously computes two sets of field displacements, both as >> they >> >> are on the reading machine and on the writing machine. For the >> latter, >> >> the value of RTPacking.T is (after a compact bit encoding) >> stored in the >> >> header of the pickle file. For the former, it's gotten by >> techniques >> >> like >> >> using BITSIZE. This is actually all done in RTTipe, part of >> m3core, and >> >> called by Pickle code. >> >> >> >> This is very fragile. RTTipe has to duplicate the compiler's >> layout >> >> behavior. There is no shared code. Making it common would >> involve >> >> quite a bit of rework, as the two use substantially different data >> >> structure and code organization. It will be obvious what kind >> of bit >> >> damage could occur if the two algorithms didn't agree. >> >> >> >> This is why I am obsessing over LAZYALIGN. I have been >> comparing the >> >> field displacement computations in RTTipe and in the compiler. >> The >> >> former is oblivious to LAZYALIGN. >> >> >> >> Note that all this is required even without any packing of small >> fields >> >> within words. E.G., a record with two INTEGER fields, pickled >> on a >> >> 32-bit machine and unpickled on a 64. >> >> >> >> Tony Hosking wrote: >> >> >> >>> Rodney, >> >>> >> >>> Why does there need to be an entry for LONGINT in RTPacking? I >> >>> would have thought all packing is done on word-sized units >> anyway. >> >>> Each side of the connection can check BITSIZE(LONGINT) to >> figure >> >>> out what to do presumably no differently from the way INTEGER is >> >>> communicated between 32-bit and 64-bit machines. Am I missing >> >>> something? >> >>> >> >>> -- Tony >> >>> >> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> >> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >> help with? >> >>>> >> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >> >>>> >> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >> >>>>> (which can vary independently of the size of INTEGER). >> >>>>> 2) Variable length values of subrange bounds found in type >> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >> >>>>> what the native word size can represent. >> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >> recently) >> >>>>> is not handled by Pickles. >> >>>>> >> >>>>> I have done some coding on this, but have been interrupted. >> >>>>> >> >>>>> Tony Hosking wrote: >> >>>>> >> >>>>>> Why is LONGINT for pickles not yet supported? >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> ------------------------------------------------------------- >> >>>>> 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 >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> ------------------------------------------------------------- >> >> 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 >> > >> > >> > >> > >> >> -- >> ------------------------------------------------------------- >> 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 hosking at cs.purdue.edu Mon Feb 18 22:32:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 16:32:46 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: On Feb 18, 2008, at 3:01 PM, Darko wrote: > The alignment behaviour is absolutely crucial to programming > natively in Mac OS X and should be kept. I have a great need for it. > > The PRGAMA is of no use and can be removed. > > Does anyone have any objections to making this alignment behaviour > standard? What do you mean make LAZYALIGN standard? Why wouldn't we go with the standard gcc-backend alignment? Perhaps I don't understand what it is you are doing or trying to do. Again, please remind me what it is that LAZYALIGN does and why it is needed. > On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > >> Can someone remind me again why we need LAZYALIGN? I concur with >> Randy that if it is rarely used and moreso breaks things I would >> argue to abandon it. >> >> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >> >>> I use pickles extensively and they are used also by network objects. >>> I've never used LAZYALIGN. >>> My vote is that we don't break something (pickles/netobj) to add >>> support for something that is rarely used. >>> Regards, >>> Randy >>> >>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>> PM >>> >>> I'll put it in comments in the code. I am sure I can fix it to >>> handle LAZYALIGN too, just not sure whether I can do it without >>> requiring existing pickle files to be regenerated and/or existing >>> code that reads/writes pickles to need recompilation. >>> >>> Anybody on this list who has code that might be affected if pickles >>> or compiled code were invalidated by a change? >>> >>> I do propose we change the way of telling the compiler to do >>> LAZYALIGN so that it is a property of a type and affects all >>> variables of that type. >>> >>> Olaf Wagner wrote: >>> > Perhaps we should check-in this description somewhere near the >>> > actual code? Or is there enough documentation already? >>> > >>> > Olaf >>> > >>> > PS: Based on your description, I'd say we should abandon >>> LAZYALIGN. >>> > Or at least put a big sticker on that it will break pickles. >>> > >>> > Quoting "Rodney M. Bates" : >>> > >>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>> BITSIZE, >>> >> etc. only works for getting object layouts as on the machine >>> executing >>> >> the code, which is all that is needed when writing a pickle. >>> >> >>> >> When reading, Pickle code needs to know the layouts of a type >>> both as >>> >> it is on the reading machine and as it was on the machine that >>> wrote >>> >> the pickle. The type description that the compiler generates is >>> >> excerpted and contains no field displacements, just lists of >>> field >>> >> types (which are either recursive type descriptions or builtin >>> types). >>> >> So it is independent of word sizes, etc. >>> >> >>> >> Pickles regenerates the displacements using the few target >>> machine >>> >> characteristics in a RTPacking.T It traverses a type >>> description and >>> >> simultaneously computes two sets of field displacements, both >>> as they >>> >> are on the reading machine and on the writing machine. For >>> the latter, >>> >> the value of RTPacking.T is (after a compact bit encoding) >>> stored in the >>> >> header of the pickle file. For the former, it's gotten by >>> techniques >>> >> like >>> >> using BITSIZE. This is actually all done in RTTipe, part of >>> m3core, and >>> >> called by Pickle code. >>> >> >>> >> This is very fragile. RTTipe has to duplicate the compiler's >>> layout >>> >> behavior. There is no shared code. Making it common would >>> involve >>> >> quite a bit of rework, as the two use substantially different >>> data >>> >> structure and code organization. It will be obvious what kind >>> of bit >>> >> damage could occur if the two algorithms didn't agree. >>> >> >>> >> This is why I am obsessing over LAZYALIGN. I have been >>> comparing the >>> >> field displacement computations in RTTipe and in the >>> compiler. The >>> >> former is oblivious to LAZYALIGN. >>> >> >>> >> Note that all this is required even without any packing of >>> small fields >>> >> within words. E.G., a record with two INTEGER fields, pickled >>> on a >>> >> 32-bit machine and unpickled on a 64. >>> >> >>> >> Tony Hosking wrote: >>> >> >>> >>> Rodney, >>> >>> >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> >>> would have thought all packing is done on word-sized units >>> anyway. >>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>> figure >>> >>> out what to do presumably no differently from the way >>> INTEGER is >>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>> >>> something? >>> >>> >>> >>> -- Tony >>> >>> >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>> >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>> help with? >>> >>>> >>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> >>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>> >>>>> (which can vary independently of the size of INTEGER). >>> >>>>> 2) Variable length values of subrange bounds found in type >>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>> >>>>> what the native word size can represent. >>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>> recently) >>> >>>>> is not handled by Pickles. >>> >>>>> >>> >>>>> I have done some coding on this, but have been interrupted. >>> >>>>> >>> >>>>> Tony Hosking wrote: >>> >>>>> >>> >>>>>> Why is LONGINT for pickles not yet supported? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> ------------------------------------------------------------- >>> >>>>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >> -- >>> >> ------------------------------------------------------------- >>> >> 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 >>> > >>> > >>> > >>> > >>> >>> -- >>> ------------------------------------------------------------- >>> 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 mika at async.caltech.edu Mon Feb 18 23:04:06 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 14:04:06 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." Message-ID: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> I never tried putting it in my PATH, no... You are right, colons are *slightly* special. I am not in the habit of copying files to Windows. I only copy files between Unix and Windows to save them from Windows. That being said, I am pretty sure I use colons more in filenames than I use the letter "q". Could you ban the letter "q" instead? :) If you've gotta do it, then do it. It's just ... weird. I personally will probably never run into the issue. I use colons in filenames a lot, but as a separator for various types of data files. :. Is your code able to import (or duplicate...) Pathname? I would have thought that that interface has all the necessary bits to make paths portable... MIka Jay writes: >--_dfd4e29a-b904-43be-8435-4824d419d270_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> But colons? Colons are not special in any way, shape, or form, on> Unix..= >. I think "it is extremely surprising" to a Unix user if a path >Ever try putting a path with a colon into $PATH? Does it work? >Or copying a file with a colon in its name to a Windows system? Does it wor= >k? >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue= >ss. >=20 >As a user switching between multiple systems, this area is quite frustratin= >g...I guess no matter what. >Sometimes one form works, sometimes another, sometimes either, often with i= >dentical meaning, but not always. >These changes, and about one more, should make building NT386GNU a fair amo= >unt easier.. >=20 >Currently it is any path with a colon in the second character. >How about if that is further restricted to having a-z in the first characte= >r and/or more importantly a slash in the third character? >=20 > - Jay > > > From jayk123 at hotmail.com Mon Feb 18 23:27:56 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 22:27:56 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: I'm going to work on this more but not today. I will at least restrict it to check that the next character is a slash. I'm not sure that will satisfy folks. The Pathname module is/was being used but is a little unsatisfactory. > I use colons in filenames a lot Do you use it in source files? For "root" directories, like where your cm3 install/source is? I'm trying to think/wiggle through what might be an acceptable escape. Something like -- where files in general are vs. where "programmer" files are. Putting a colon in a filename really is quite non-portable. And that may or may not matter. The existing Modula-3 code was fairly strict and I very unsure it was right. I had a question drafted to m3devel that I ended up not sending. It went roughly like: " Has anyone done a cross build where host and target vary in naming conventions? I am skeptical that this works, and am strongly considering /slightly/ depending on that or making it "worse". In particular, there is provision in the code for "converting" between host and target paths, but all it does is translate slashes. It doesn't translate libfoo.a to foo.lib for example. " Upon further digging though, I decide that my more immediate severe problem could be dealt with not by making things worse but by making them better. This is the change around checking NAMING_CONVENTIONS earlier. While my analysis was not 100% thorough, it is my very strong suspicion that the NAMING_CONVENTION and undocumented TARGET_NAMING configuration variables never really worked. Sure, they affected the name of the .m3x file. But that is about it. I didn't check .exes, but probably didn't work, and what I was seeing was they didn't work for libraries. M3Path.m3 sets up one set of path data in three ways. variable initialization (VAR foo := 123) module initialization (BEGIN foo := 456 END Module.) and explicit calls after reading the config file The problem was that the explicit calls were very late, so the module initialization is what held. If Join(a,b) == a/b, then you'd get Unix naming conventions. /Arguably/ this is exactly correct. But I would like the slash and the "naming" to be separate, at least for now. That is, NT386GNU uses forward slashes but foo.lib instead of libfoo.a. I should try to change that actually. I had trouble changing it for this reason since I was cross building from NT386. The NT386 HOST wants to use Win32 naming conventions, "\" and foo.lib, even if the config file asks for Unix naming.. Anyway, this is all somewhat of a tangent, one in which I'm more confident of where to go and that what I changed is ok. (It might become irrelevant.) The other issues are around "difficulty" setting paths. I had CM3_ROOT=c:\dev2\cm3.2. That wouldn't necessarily work with NT386GNU. It seems darn near possible to have one path syntax and one set of code for dealing with it. But maybe not. Even semicolon vs. colon seems doable. Specifically, if an element of $PATH appears to be just a single character, that colon is not a $PATH divider. Perhaps I just need to have two sets of CM3_ROOT / CM3_INSTALL and perhaps M3CONFIG variables. I was kind of hoping not. It's worse than that really, since the two hosts can target the two targets, so host and target paths needs to be better distinguished than I believe the are now. I was saying there is code to change the slashes, but there isn't code to deal with a leading drive letter. What I have been particularly avoiding is calls out to cygwin_convert_path or such, but maybe that's what I need to do. Get ROOT / CM3_INSTALL etc. from the command line and environment, convert as appropriate, and move on. ROOT in particular is set by Python. Usually for me that is Win32 Python, but Cygwin Python is an option. So then Python has to know what cm3 it is running? I considered probing it with findstr /i /m cm3.exe cygwin1.dll. I considered something like cm3 -report_something_or_other, kind of like gcc has -print-gcc-lib-name or whatnot. These might still be viable ideas. Historically cross environments don't allow multiple "targets" / "platforms" / "configurations" / "whatever" to run on the same OS. But there is some of an opposite trend. Like how NT386 and NT386GNU run on the same OS. Like SOLsun, SOLgnu. Like x86 on AMD64 operating systems. So maybe a little bit of support is good there, the cm3 -print-slash or cm3 -print-host or something. Also I forgot to point out that Win32 is often find with forward slashes, but notable file.open dialogs are not. I very frequently copy compiler output to file.open dialogs so in some places backward slashes are preferred. A possible strategy is to sniff what the user is using -- such as in any of those environment variables -- and favor it. Or for each Join operating harvest a path separater from the parameters and default if there is none there. I have some code working like that last option right now but it's not quite working and has to wait. It is very reasonable to have Win32 treat forward and backward slashes as the same, in particular. It is fairly reasonable imho for Posix code to also treat them the same but "fixup" backward to forward. As well, on Windows, if you mostly limit yourself to one drive letter, then /foo/bar is a pretty acceptable form.. Anyway...lots of facts, some easy conclusions, some unclear conclusions. I'll fiddle around with it more later. Ideally switching between NT386 and NT386GNU is fairly easy.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 18 Feb 2008 14:04:06 -0800> From: mika at async.caltech.edu> > > I never tried putting it in my PATH, no... You are right, colons> are *slightly* special. I am not in the habit of copying files to> Windows. I only copy files between Unix and Windows to save them> from Windows.> > That being said, I am pretty sure I use colons more in filenames> than I use the letter "q". Could you ban the letter "q" instead? :)> > If you've gotta do it, then do it. It's just ... weird.> > I personally will probably never run into the issue. I use colons> in filenames a lot, but as a separator for various types of data> files. :.> > Is your code able to import (or duplicate...) Pathname? I would> have thought that that interface has all the necessary bits to make> paths portable...> > MIka> > Jay writes:> >--_dfd4e29a-b904-43be-8435-4824d419d270_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> But colons? Colons are not special in any way, shape, or form, on> Unix..=> >. I think "it is extremely surprising" to a Unix user if a path> >Ever try putting a path with a colon into $PATH? Does it work?> >Or copying a file with a colon in its name to a Windows system? Does it wor=> >k?> >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue=> >ss.> >=20> >As a user switching between multiple systems, this area is quite frustratin=> >g...I guess no matter what.> >Sometimes one form works, sometimes another, sometimes either, often with i=> >dentical meaning, but not always.> >These changes, and about one more, should make building NT386GNU a fair amo=> >unt easier..> >=20> >Currently it is any path with a colon in the second character.> >How about if that is further restricted to having a-z in the first characte=> >r and/or more importantly a slash in the third character?> >=20> > - Jay> >> >> > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Feb 19 02:44:02 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 02:44:02 +0100 (CET) Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> Message-ID: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Actually rather than compilain rather grumpily, maybe I can just make the changes required to RTTipe and do the work to reomve the pragma. I can work with Randy to ensure it doesn't break pickles, there is no reason why it should. On tha subject Randy, I assume pickles encode the number of BITS FOR for a field? If not it should. > We seem to be going through these same point several times. I'm not sure > what the difficulty is, I'm just repeating myself. > > Keep in mind this applies *only* to packed structures, ie BIT FOR or bit > fields. > > The change I put in libralised the *M3* alignment rules so that BITS FOR > fields in structures would align on byte boundries if possible instead of > restricting them to word alignment generally. GCC happily generates code > for this. There may be restrictions in GCC's C as to how you can arrange > bit fields but I don't see what they have to do with M3. > > This is absolutely essentail for using the native APIs on Mac OS X and its > removal would make M3 pointless for use on the Mac, at least more me. > > This should be the default behviour. If you are using BITS FOR it's > becuase you want to arrange the fields in a record in particular way. Why > then arbitrarliy pad out the fields? If performance is an issue, the user > should be using appropriate field bit sizes. The implementation rule for > BITS FOR in M3 is implementation dependent, there are no language issues. > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > created and had nothing to do with me. I diagreed with it and never used > it in the version of the compiler I ran. I support its removal. > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: >> >>> The alignment behaviour is absolutely crucial to programming >>> natively in Mac OS X and should be kept. I have a great need for it. >>> >>> The PRGAMA is of no use and can be removed. >>> >>> Does anyone have any objections to making this alignment behaviour >>> standard? >> >> What do you mean make LAZYALIGN standard? Why wouldn't we go with >> the standard gcc-backend alignment? Perhaps I don't understand what >> it is you are doing or trying to do. Again, please remind me what it >> is that LAZYALIGN does and why it is needed. >> >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>> >>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>> Randy that if it is rarely used and moreso breaks things I would >>>> argue to abandon it. >>>> >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>> >>>>> I use pickles extensively and they are used also by network objects. >>>>> I've never used LAZYALIGN. >>>>> My vote is that we don't break something (pickles/netobj) to add >>>>> support for something that is rarely used. >>>>> Regards, >>>>> Randy >>>>> >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>>> PM >>> >>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>> requiring existing pickle files to be regenerated and/or existing >>>>> code that reads/writes pickles to need recompilation. >>>>> >>>>> Anybody on this list who has code that might be affected if pickles >>>>> or compiled code were invalidated by a change? >>>>> >>>>> I do propose we change the way of telling the compiler to do >>>>> LAZYALIGN so that it is a property of a type and affects all >>>>> variables of that type. >>>>> >>>>> Olaf Wagner wrote: >>>>> > Perhaps we should check-in this description somewhere near the >>>>> > actual code? Or is there enough documentation already? >>>>> > >>>>> > Olaf >>>>> > >>>>> > PS: Based on your description, I'd say we should abandon >>>>> LAZYALIGN. >>>>> > Or at least put a big sticker on that it will break pickles. >>>>> > >>>>> > Quoting "Rodney M. Bates" : >>>>> > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>>> BITSIZE, >>>>> >> etc. only works for getting object layouts as on the machine >>>>> executing >>>>> >> the code, which is all that is needed when writing a pickle. >>>>> >> >>>>> >> When reading, Pickle code needs to know the layouts of a type >>>>> both as >>>>> >> it is on the reading machine and as it was on the machine that >>>>> wrote >>>>> >> the pickle. The type description that the compiler generates is >>>>> >> excerpted and contains no field displacements, just lists of >>>>> field >>>>> >> types (which are either recursive type descriptions or builtin >>>>> types). >>>>> >> So it is independent of word sizes, etc. >>>>> >> >>>>> >> Pickles regenerates the displacements using the few target >>>>> machine >>>>> >> characteristics in a RTPacking.T It traverses a type >>>>> description and >>>>> >> simultaneously computes two sets of field displacements, both >>>>> as they >>>>> >> are on the reading machine and on the writing machine. For >>>>> the latter, >>>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>>> stored in the >>>>> >> header of the pickle file. For the former, it's gotten by >>>>> techniques >>>>> >> like >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>>> m3core, and >>>>> >> called by Pickle code. >>>>> >> >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>>> layout >>>>> >> behavior. There is no shared code. Making it common would >>>>> involve >>>>> >> quite a bit of rework, as the two use substantially different >>>>> data >>>>> >> structure and code organization. It will be obvious what kind >>>>> of bit >>>>> >> damage could occur if the two algorithms didn't agree. >>>>> >> >>>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>>> comparing the >>>>> >> field displacement computations in RTTipe and in the >>>>> compiler. The >>>>> >> former is oblivious to LAZYALIGN. >>>>> >> >>>>> >> Note that all this is required even without any packing of >>>>> small fields >>>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>>> on a >>>>> >> 32-bit machine and unpickled on a 64. >>>>> >> >>>>> >> Tony Hosking wrote: >>>>> >> >>>>> >>> Rodney, >>>>> >>> >>>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>> >>> would have thought all packing is done on word-sized units >>>>> anyway. >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>>> figure >>>>> >>> out what to do presumably no differently from the way >>>>> INTEGER is >>>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>>> >>> something? >>>>> >>> >>>>> >>> -- Tony >>>>> >>> >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>> >>> >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>> help with? >>>>> >>>> >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>> >>>> >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> >>>>> (which can vary independently of the size of INTEGER). >>>>> >>>>> 2) Variable length values of subrange bounds found in type >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> >>>>> what the native word size can represent. >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>> recently) >>>>> >>>>> is not handled by Pickles. >>>>> >>>>> >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>> >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------------------------------------------------------------- >>>>> >>>>> 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 >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> -- >>>>> >> ------------------------------------------------------------- >>>>> >> 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 >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 hosking at cs.purdue.edu Tue Feb 19 05:40:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 23:40:47 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Message-ID: <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> Thanks for the explanation! How does one express the alignment you support? It does sound like <*LAZYALIGN*> can go away. On Feb 18, 2008, at 8:44 PM, Darko wrote: > Actually rather than compilain rather grumpily, maybe I can just > make the > changes required to RTTipe and do the work to reomve the pragma. I can > work with Randy to ensure it doesn't break pickles, there is no > reason why > it should. > > On tha subject Randy, I assume pickles encode the number of BITS FOR > for a field? If not it should. > > >> We seem to be going through these same point several times. I'm >> not sure >> what the difficulty is, I'm just repeating myself. >> >> Keep in mind this applies *only* to packed structures, ie BIT FOR >> or bit >> fields. >> >> The change I put in libralised the *M3* alignment rules so that >> BITS FOR >> fields in structures would align on byte boundries if possible >> instead of >> restricting them to word alignment generally. GCC happily >> generates code >> for this. There may be restrictions in GCC's C as to how you can >> arrange >> bit fields but I don't see what they have to do with M3. >> >> This is absolutely essentail for using the native APIs on Mac OS X >> and its >> removal would make M3 pointless for use on the Mac, at least more me. >> >> This should be the default behviour. If you are using BITS FOR it's >> becuase you want to arrange the fields in a record in particular >> way. Why >> then arbitrarliy pad out the fields? If performance is an issue, >> the user >> should be using appropriate field bit sizes. The implementation >> rule for >> BITS FOR in M3 is implementation dependent, there are no language >> issues. >> >> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >> created and had nothing to do with me. I diagreed with it and >> never used >> it in the version of the compiler I ran. I support its removal. >> >> >> >>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>> >>>> The alignment behaviour is absolutely crucial to programming >>>> natively in Mac OS X and should be kept. I have a great need for >>>> it. >>>> >>>> The PRGAMA is of no use and can be removed. >>>> >>>> Does anyone have any objections to making this alignment behaviour >>>> standard? >>> >>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>> the standard gcc-backend alignment? Perhaps I don't understand what >>> it is you are doing or trying to do. Again, please remind me >>> what it >>> is that LAZYALIGN does and why it is needed. >>> >>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>> >>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>> Randy that if it is rarely used and moreso breaks things I would >>>>> argue to abandon it. >>>>> >>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>> >>>>>> I use pickles extensively and they are used also by network >>>>>> objects. >>>>>> I've never used LAZYALIGN. >>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>> support for something that is rarely used. >>>>>> Regards, >>>>>> Randy >>>>>> >>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>> PM >>> >>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>> requiring existing pickle files to be regenerated and/or existing >>>>>> code that reads/writes pickles to need recompilation. >>>>>> >>>>>> Anybody on this list who has code that might be affected if >>>>>> pickles >>>>>> or compiled code were invalidated by a change? >>>>>> >>>>>> I do propose we change the way of telling the compiler to do >>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>> variables of that type. >>>>>> >>>>>> Olaf Wagner wrote: >>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>> actual code? Or is there enough documentation already? >>>>>>> >>>>>>> Olaf >>>>>>> >>>>>>> PS: Based on your description, I'd say we should abandon >>>>>> LAZYALIGN. >>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>> >>>>>>> Quoting "Rodney M. Bates" : >>>>>>> >>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>> BITSIZE, >>>>>>>> etc. only works for getting object layouts as on the machine >>>>>> executing >>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>> >>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>> both as >>>>>>>> it is on the reading machine and as it was on the machine that >>>>>> wrote >>>>>>>> the pickle. The type description that the compiler >>>>>>>> generates is >>>>>>>> excerpted and contains no field displacements, just lists of >>>>>> field >>>>>>>> types (which are either recursive type descriptions or builtin >>>>>> types). >>>>>>>> So it is independent of word sizes, etc. >>>>>>>> >>>>>>>> Pickles regenerates the displacements using the few target >>>>>> machine >>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>> description and >>>>>>>> simultaneously computes two sets of field displacements, both >>>>>> as they >>>>>>>> are on the reading machine and on the writing machine. For >>>>>> the latter, >>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>> stored in the >>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>> techniques >>>>>>>> like >>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>> m3core, and >>>>>>>> called by Pickle code. >>>>>>>> >>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>> layout >>>>>>>> behavior. There is no shared code. Making it common would >>>>>> involve >>>>>>>> quite a bit of rework, as the two use substantially different >>>>>> data >>>>>>>> structure and code organization. It will be obvious what kind >>>>>> of bit >>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>> >>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>> comparing the >>>>>>>> field displacement computations in RTTipe and in the >>>>>> compiler. The >>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>> >>>>>>>> Note that all this is required even without any packing of >>>>>> small fields >>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>> on a >>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>> >>>>>>>> Tony Hosking wrote: >>>>>>>> >>>>>>>>> Rodney, >>>>>>>>> >>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>> RTPacking? I >>>>>>>>> would have thought all packing is done on word-sized units >>>>>> anyway. >>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>> figure >>>>>>>>> out what to do presumably no differently from the way >>>>>> INTEGER is >>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>> missing >>>>>>>>> something? >>>>>>>>> >>>>>>>>> -- Tony >>>>>>>>> >>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>> help with? >>>>>>>>>> >>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>> >>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>> LONGINT, >>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>> what the native word size can represent. >>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>> recently) >>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>> >>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>> - >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------- >>>>>> 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 rcoleburn at scires.com Tue Feb 19 05:52:26 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 18 Feb 2008 23:52:26 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Message-ID: <47BA1A35.1E75.00D7.1@scires.com> Sorry, but I've never checked to see how pickles represent "BITS FOR". I've used BITS FOR only on rare occasion. My concern about "breaking" is that if a change is made to the encoding of pickles, then all other programs that use pickles would need to be rebuilt in order to remain compatible. I seem to recall that there is a version number that is put into the encoding to help with compatibility and of course we already have pickle, pickle2, netobj, and netobj2. Perhaps your change could be structured in such a way as to still understand the older variants for compatibility. Here is a scenario: Suppose I have a program that uses pickles and/or netobj. A version is built and put into an embedded system. This system shares pickles/netobj with another client program. After the embedded system is fielded, a change is made to the encoding of pickles. New features are added to the client program and it is rebuilt. Now the client program can't share pickles with the embedded system. Scenario2: A program uses pickles to store data in files. If the pickle structure is changed, the program will no longer be able to read its old files without some sort of transformation function on all the files. Regards, Randy >>> "Darko" 2/18/2008 8:44 PM >>> Actually rather than compilain rather grumpily, maybe I can just make the changes required to RTTipe and do the work to reomve the pragma. I can work with Randy to ensure it doesn't break pickles, there is no reason why it should. On tha subject Randy, I assume pickles encode the number of BITS FOR for a field? If not it should. > We seem to be going through these same point several times. I'm not sure > what the difficulty is, I'm just repeating myself. > > Keep in mind this applies *only* to packed structures, ie BIT FOR or bit > fields. > > The change I put in libralised the *M3* alignment rules so that BITS FOR > fields in structures would align on byte boundries if possible instead of > restricting them to word alignment generally. GCC happily generates code > for this. There may be restrictions in GCC's C as to how you can arrange > bit fields but I don't see what they have to do with M3. > > This is absolutely essentail for using the native APIs on Mac OS X and its > removal would make M3 pointless for use on the Mac, at least more me. > > This should be the default behviour. If you are using BITS FOR it's > becuase you want to arrange the fields in a record in particular way. Why > then arbitrarliy pad out the fields? If performance is an issue, the user > should be using appropriate field bit sizes. The implementation rule for > BITS FOR in M3 is implementation dependent, there are no language issues. > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > created and had nothing to do with me. I diagreed with it and never used > it in the version of the compiler I ran. I support its removal. > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: >> >>> The alignment behaviour is absolutely crucial to programming >>> natively in Mac OS X and should be kept. I have a great need for it. >>> >>> The PRGAMA is of no use and can be removed. >>> >>> Does anyone have any objections to making this alignment behaviour >>> standard? >> >> What do you mean make LAZYALIGN standard? Why wouldn't we go with >> the standard gcc-backend alignment? Perhaps I don't understand what >> it is you are doing or trying to do. Again, please remind me what it >> is that LAZYALIGN does and why it is needed. >> >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>> >>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>> Randy that if it is rarely used and moreso breaks things I would >>>> argue to abandon it. >>>> >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>> >>>>> I use pickles extensively and they are used also by network objects. >>>>> I've never used LAZYALIGN. >>>>> My vote is that we don't break something (pickles/netobj) to add >>>>> support for something that is rarely used. >>>>> Regards, >>>>> Randy >>>>> >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>>> PM >>> >>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>> requiring existing pickle files to be regenerated and/or existing >>>>> code that reads/writes pickles to need recompilation. >>>>> >>>>> Anybody on this list who has code that might be affected if pickles >>>>> or compiled code were invalidated by a change? >>>>> >>>>> I do propose we change the way of telling the compiler to do >>>>> LAZYALIGN so that it is a property of a type and affects all >>>>> variables of that type. >>>>> >>>>> Olaf Wagner wrote: >>>>> > Perhaps we should check-in this description somewhere near the >>>>> > actual code? Or is there enough documentation already? >>>>> > >>>>> > Olaf >>>>> > >>>>> > PS: Based on your description, I'd say we should abandon >>>>> LAZYALIGN. >>>>> > Or at least put a big sticker on that it will break pickles. >>>>> > >>>>> > Quoting "Rodney M. Bates" : >>>>> > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>>> BITSIZE, >>>>> >> etc. only works for getting object layouts as on the machine >>>>> executing >>>>> >> the code, which is all that is needed when writing a pickle. >>>>> >> >>>>> >> When reading, Pickle code needs to know the layouts of a type >>>>> both as >>>>> >> it is on the reading machine and as it was on the machine that >>>>> wrote >>>>> >> the pickle. The type description that the compiler generates is >>>>> >> excerpted and contains no field displacements, just lists of >>>>> field >>>>> >> types (which are either recursive type descriptions or builtin >>>>> types). >>>>> >> So it is independent of word sizes, etc. >>>>> >> >>>>> >> Pickles regenerates the displacements using the few target >>>>> machine >>>>> >> characteristics in a RTPacking.T It traverses a type >>>>> description and >>>>> >> simultaneously computes two sets of field displacements, both >>>>> as they >>>>> >> are on the reading machine and on the writing machine. For >>>>> the latter, >>>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>>> stored in the >>>>> >> header of the pickle file. For the former, it's gotten by >>>>> techniques >>>>> >> like >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>>> m3core, and >>>>> >> called by Pickle code. >>>>> >> >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>>> layout >>>>> >> behavior. There is no shared code. Making it common would >>>>> involve >>>>> >> quite a bit of rework, as the two use substantially different >>>>> data >>>>> >> structure and code organization. It will be obvious what kind >>>>> of bit >>>>> >> damage could occur if the two algorithms didn't agree. >>>>> >> >>>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>>> comparing the >>>>> >> field displacement computations in RTTipe and in the >>>>> compiler. The >>>>> >> former is oblivious to LAZYALIGN. >>>>> >> >>>>> >> Note that all this is required even without any packing of >>>>> small fields >>>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>>> on a >>>>> >> 32-bit machine and unpickled on a 64. >>>>> >> >>>>> >> Tony Hosking wrote: >>>>> >> >>>>> >>> Rodney, >>>>> >>> >>>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>> >>> would have thought all packing is done on word-sized units >>>>> anyway. >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>>> figure >>>>> >>> out what to do presumably no differently from the way >>>>> INTEGER is >>>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>>> >>> something? >>>>> >>> >>>>> >>> -- Tony >>>>> >>> >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>> >>> >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>> help with? >>>>> >>>> >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>> >>>> >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> >>>>> (which can vary independently of the size of INTEGER). >>>>> >>>>> 2) Variable length values of subrange bounds found in type >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> >>>>> what the native word size can represent. >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>> recently) >>>>> >>>>> is not handled by Pickles. >>>>> >>>>> >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>> >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------------------------------------------------------------- >>>>> >>>>> 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 >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> -- >>>>> >> ------------------------------------------------------------- >>>>> >> 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 >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 darko at darko.org Tue Feb 19 11:02:16 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:02:16 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> Message-ID: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> There wouldn't be any explicit expression. in the source, but there would be a flag in Target.i3 for turning it off and on for different platforms. Although the details may be a bit off, the principal is this: before byte alignment change: RECORD a: BITS 8 FOR 0..255; (* takes 32 bits *) b: BITS 32 FOR INTEGER; (* takes 32 bits *) c: BITS 16 FOR 0..65000; (* takes 32 bits *) END; after byte alignment change: RECORD a: BITS 8 FOR 0..255; (* takes 8 bits *) b: BITS 32 FOR INTEGER; (* takes 32 bits *) c: BITS 16 FOR 0..65000; (* takes 16 bits *) END; On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > Thanks for the explanation! How does one express the alignment you > support? > > It does sound like <*LAZYALIGN*> can go away. > > On Feb 18, 2008, at 8:44 PM, Darko wrote: > >> Actually rather than compilain rather grumpily, maybe I can just >> make the >> changes required to RTTipe and do the work to reomve the pragma. I >> can >> work with Randy to ensure it doesn't break pickles, there is no >> reason why >> it should. >> >> On tha subject Randy, I assume pickles encode the number of BITS FOR >> for a field? If not it should. >> >> >>> We seem to be going through these same point several times. I'm >>> not sure >>> what the difficulty is, I'm just repeating myself. >>> >>> Keep in mind this applies *only* to packed structures, ie BIT FOR >>> or bit >>> fields. >>> >>> The change I put in libralised the *M3* alignment rules so that >>> BITS FOR >>> fields in structures would align on byte boundries if possible >>> instead of >>> restricting them to word alignment generally. GCC happily >>> generates code >>> for this. There may be restrictions in GCC's C as to how you can >>> arrange >>> bit fields but I don't see what they have to do with M3. >>> >>> This is absolutely essentail for using the native APIs on Mac OS X >>> and its >>> removal would make M3 pointless for use on the Mac, at least more >>> me. >>> >>> This should be the default behviour. If you are using BITS FOR it's >>> becuase you want to arrange the fields in a record in particular >>> way. Why >>> then arbitrarliy pad out the fields? If performance is an issue, >>> the user >>> should be using appropriate field bit sizes. The implementation >>> rule for >>> BITS FOR in M3 is implementation dependent, there are no language >>> issues. >>> >>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>> created and had nothing to do with me. I diagreed with it and >>> never used >>> it in the version of the compiler I ran. I support its removal. >>> >>> >>> >>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>> >>>>> The alignment behaviour is absolutely crucial to programming >>>>> natively in Mac OS X and should be kept. I have a great need for >>>>> it. >>>>> >>>>> The PRGAMA is of no use and can be removed. >>>>> >>>>> Does anyone have any objections to making this alignment behaviour >>>>> standard? >>>> >>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>> the standard gcc-backend alignment? Perhaps I don't understand >>>> what >>>> it is you are doing or trying to do. Again, please remind me >>>> what it >>>> is that LAZYALIGN does and why it is needed. >>>> >>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>> >>>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>> argue to abandon it. >>>>>> >>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>> >>>>>>> I use pickles extensively and they are used also by network >>>>>>> objects. >>>>>>> I've never used LAZYALIGN. >>>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>>> support for something that is rarely used. >>>>>>> Regards, >>>>>>> Randy >>>>>>> >>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>> PM >>> >>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>> existing >>>>>>> code that reads/writes pickles to need recompilation. >>>>>>> >>>>>>> Anybody on this list who has code that might be affected if >>>>>>> pickles >>>>>>> or compiled code were invalidated by a change? >>>>>>> >>>>>>> I do propose we change the way of telling the compiler to do >>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>> variables of that type. >>>>>>> >>>>>>> Olaf Wagner wrote: >>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>> actual code? Or is there enough documentation already? >>>>>>>> >>>>>>>> Olaf >>>>>>>> >>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>> LAZYALIGN. >>>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>>> >>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>> >>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>> BITSIZE, >>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>> executing >>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>> >>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>> both as >>>>>>>>> it is on the reading machine and as it was on the machine that >>>>>>> wrote >>>>>>>>> the pickle. The type description that the compiler >>>>>>>>> generates is >>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>> field >>>>>>>>> types (which are either recursive type descriptions or builtin >>>>>>> types). >>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>> >>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>> machine >>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>> description and >>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>> as they >>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>> the latter, >>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>> stored in the >>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>> techniques >>>>>>>>> like >>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>> m3core, and >>>>>>>>> called by Pickle code. >>>>>>>>> >>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>> layout >>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>> involve >>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>> data >>>>>>>>> structure and code organization. It will be obvious what kind >>>>>>> of bit >>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>> >>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>> comparing the >>>>>>>>> field displacement computations in RTTipe and in the >>>>>>> compiler. The >>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>> >>>>>>>>> Note that all this is required even without any packing of >>>>>>> small fields >>>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>>> on a >>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>> >>>>>>>>> Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> Rodney, >>>>>>>>>> >>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>> RTPacking? I >>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>> anyway. >>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>> figure >>>>>>>>>> out what to do presumably no differently from the way >>>>>>> INTEGER is >>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>> missing >>>>>>>>>> something? >>>>>>>>>> >>>>>>>>>> -- Tony >>>>>>>>>> >>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>> help with? >>>>>>>>>>> >>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>> >>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>> LONGINT, >>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>> recently) >>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>> >>>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>>> >>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------- >>>>>>> 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 darko at darko.org Tue Feb 19 09:50:38 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 19:50:38 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BA1A35.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <47BA1A35.1E75.00D7.1@scires.com> Message-ID: I agree that pickles should not break. I'm not convinced this alignment change break pickles since it doesn't do anything but change the padding of fields in structures, which is going to change between platforms anyway. Or maybe pickles don't support bit fields anyway. Do pickles use RTTipe exclusively or does it do its own hacking too? On 19/02/2008, at 3:52 PM, Randy Coleburn wrote: > Sorry, but I've never checked to see how pickles represent "BITS FOR". > I've used BITS FOR only on rare occasion. > > My concern about "breaking" is that if a change is made to the > encoding of pickles, then all other programs that use pickles would > need to be rebuilt in order to remain compatible. I seem to recall > that there is a version number that is put into the encoding to help > with compatibility and of course we already have pickle, pickle2, > netobj, and netobj2. Perhaps your change could be structured in > such a way as to still understand the older variants for > compatibility. > > Here is a scenario: Suppose I have a program that uses pickles and/ > or netobj. A version is built and put into an embedded system. > This system shares pickles/netobj with another client program. > After the embedded system is fielded, a change is made to the > encoding of pickles. New features are added to the client program > and it is rebuilt. Now the client program can't share pickles with > the embedded system. > > Scenario2: A program uses pickles to store data in files. If the > pickle structure is changed, the program will no longer be able to > read its old files without some sort of transformation function on > all the files. > > Regards, > Randy > > >>> "Darko" 2/18/2008 8:44 PM >>> > Actually rather than compilain rather grumpily, maybe I can just > make the > changes required to RTTipe and do the work to reomve the pragma. I can > work with Randy to ensure it doesn't break pickles, there is no > reason why > it should. > > On tha subject Randy, I assume pickles encode the number of BITS FOR > for a field? If not it should. > > > > We seem to be going through these same point several times. I'm > not sure > > what the difficulty is, I'm just repeating myself. > > > > Keep in mind this applies *only* to packed structures, ie BIT FOR > or bit > > fields. > > > > The change I put in libralised the *M3* alignment rules so that > BITS FOR > > fields in structures would align on byte boundries if possible > instead of > > restricting them to word alignment generally. GCC happily > generates code > > for this. There may be restrictions in GCC's C as to how you can > arrange > > bit fields but I don't see what they have to do with M3. > > > > This is absolutely essentail for using the native APIs on Mac OS X > and its > > removal would make M3 pointless for use on the Mac, at least more > me. > > > > This should be the default behviour. If you are using BITS FOR it's > > becuase you want to arrange the fields in a record in particular > way. Why > > then arbitrarliy pad out the fields? If performance is an issue, > the user > > should be using appropriate field bit sizes. The implementation > rule for > > BITS FOR in M3 is implementation dependent, there are no language > issues. > > > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > > created and had nothing to do with me. I diagreed with it and > never used > > it in the version of the compiler I ran. I support its removal. > > > > > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: > >> > >>> The alignment behaviour is absolutely crucial to programming > >>> natively in Mac OS X and should be kept. I have a great need for > it. > >>> > >>> The PRGAMA is of no use and can be removed. > >>> > >>> Does anyone have any objections to making this alignment behaviour > >>> standard? > >> > >> What do you mean make LAZYALIGN standard? Why wouldn't we go with > >> the standard gcc-backend alignment? Perhaps I don't understand > what > >> it is you are doing or trying to do. Again, please remind me > what it > >> is that LAZYALIGN does and why it is needed. > >> > >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > >>> > >>>> Can someone remind me again why we need LAZYALIGN? I concur with > >>>> Randy that if it is rarely used and moreso breaks things I would > >>>> argue to abandon it. > >>>> > >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > >>>> > >>>>> I use pickles extensively and they are used also by network > objects. > >>>>> I've never used LAZYALIGN. > >>>>> My vote is that we don't break something (pickles/netobj) to add > >>>>> support for something that is rarely used. > >>>>> Regards, > >>>>> Randy > >>>>> > >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 > >>>>> PM >>> > >>>>> I'll put it in comments in the code. I am sure I can fix it to > >>>>> handle LAZYALIGN too, just not sure whether I can do it without > >>>>> requiring existing pickle files to be regenerated and/or > existing > >>>>> code that reads/writes pickles to need recompilation. > >>>>> > >>>>> Anybody on this list who has code that might be affected if > pickles > >>>>> or compiled code were invalidated by a change? > >>>>> > >>>>> I do propose we change the way of telling the compiler to do > >>>>> LAZYALIGN so that it is a property of a type and affects all > >>>>> variables of that type. > >>>>> > >>>>> Olaf Wagner wrote: > >>>>> > Perhaps we should check-in this description somewhere near the > >>>>> > actual code? Or is there enough documentation already? > >>>>> > > >>>>> > Olaf > >>>>> > > >>>>> > PS: Based on your description, I'd say we should abandon > >>>>> LAZYALIGN. > >>>>> > Or at least put a big sticker on that it will break > pickles. > >>>>> > > >>>>> > Quoting "Rodney M. Bates" : > >>>>> > > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using > >>>>> BITSIZE, > >>>>> >> etc. only works for getting object layouts as on the machine > >>>>> executing > >>>>> >> the code, which is all that is needed when writing a pickle. > >>>>> >> > >>>>> >> When reading, Pickle code needs to know the layouts of a type > >>>>> both as > >>>>> >> it is on the reading machine and as it was on the machine > that > >>>>> wrote > >>>>> >> the pickle. The type description that the compiler > generates is > >>>>> >> excerpted and contains no field displacements, just lists of > >>>>> field > >>>>> >> types (which are either recursive type descriptions or > builtin > >>>>> types). > >>>>> >> So it is independent of word sizes, etc. > >>>>> >> > >>>>> >> Pickles regenerates the displacements using the few target > >>>>> machine > >>>>> >> characteristics in a RTPacking.T It traverses a type > >>>>> description and > >>>>> >> simultaneously computes two sets of field displacements, both > >>>>> as they > >>>>> >> are on the reading machine and on the writing machine. For > >>>>> the latter, > >>>>> >> the value of RTPacking.T is (after a compact bit encoding) > >>>>> stored in the > >>>>> >> header of the pickle file. For the former, it's gotten by > >>>>> techniques > >>>>> >> like > >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of > >>>>> m3core, and > >>>>> >> called by Pickle code. > >>>>> >> > >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's > >>>>> layout > >>>>> >> behavior. There is no shared code. Making it common would > >>>>> involve > >>>>> >> quite a bit of rework, as the two use substantially different > >>>>> data > >>>>> >> structure and code organization. It will be obvious what > kind > >>>>> of bit > >>>>> >> damage could occur if the two algorithms didn't agree. > >>>>> >> > >>>>> >> This is why I am obsessing over LAZYALIGN. I have been > >>>>> comparing the > >>>>> >> field displacement computations in RTTipe and in the > >>>>> compiler. The > >>>>> >> former is oblivious to LAZYALIGN. > >>>>> >> > >>>>> >> Note that all this is required even without any packing of > >>>>> small fields > >>>>> >> within words. E.G., a record with two INTEGER fields, > pickled > >>>>> on a > >>>>> >> 32-bit machine and unpickled on a 64. > >>>>> >> > >>>>> >> Tony Hosking wrote: > >>>>> >> > >>>>> >>> Rodney, > >>>>> >>> > >>>>> >>> Why does there need to be an entry for LONGINT in > RTPacking? I > >>>>> >>> would have thought all packing is done on word-sized units > >>>>> anyway. > >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to > >>>>> figure > >>>>> >>> out what to do presumably no differently from the way > >>>>> INTEGER is > >>>>> >>> communicated between 32-bit and 64-bit machines. Am I > missing > >>>>> >>> something? > >>>>> >>> > >>>>> >>> -- Tony > >>>>> >>> > >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >>>>> >>> > >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can > >>>>> help with? > >>>>> >>>> > >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >>>>> >>>> > >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for > LONGINT, > >>>>> >>>>> (which can vary independently of the size of INTEGER). > >>>>> >>>>> 2) Variable length values of subrange bounds found in type > >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond > >>>>> >>>>> what the native word size can represent. > >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added > >>>>> recently) > >>>>> >>>>> is not handled by Pickles. > >>>>> >>>>> > >>>>> >>>>> I have done some coding on this, but have been > interrupted. > >>>>> >>>>> > >>>>> >>>>> Tony Hosking wrote: > >>>>> >>>>> > >>>>> >>>>>> Why is LONGINT for pickles not yet supported? > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> > ------------------------------------------------------------- > >>>>> >>>>> 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 > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >> > >>>>> >> -- > >>>>> >> ------------------------------------------------------------- > >>>>> >> 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 > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> -- > >>>>> ------------------------------------------------------------- > >>>>> 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 darko at darko.org Tue Feb 19 11:04:09 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:04:09 +1100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> I agree that there should be a pre-processor between M3 syntax and C syntax, but this should also be integrated into the build system so that it is transparent. I think the '.mc' extension is already taken though, which is a bummer. I think we should also be aiming to use this tool to automatically convert C header files (with limitations) to M3. The more I think about it the more I wonder if C programers will swallow it: for example VAR params? Further comments are embedded... On 18/02/2008, at 3:26 PM, Jay wrote: > I've been trying to stay out of this... I would have though your input was most appropriate since your a member of the target audience. > If a comment at the top of the file can make the Modula-3 syntax > more like C then.. Not really what we're aiming for. We're looking for a separate C like syntax in separate files. > replace = with == yes > replace := with = yes > make assignment an expression no, that changes the abstract syntax, which is something we're trying to avoid. > lowercase the keywords yes > try to make braces work (with some alteration for C) yes > use type name instead of name : type yes > separate function parameters with commas and require each to state > its type yes > for that matter, subset C and require all declarations be separate > like that? Do you think C programmers would object? > put back ++, --, -=, +=, etc. yes > superset C and let . be used in place of -> yes > new coding style is four space indent with opening braces on their > own line :) I don't do that even in C > Hm. I think if anyone really wants to do this, instead of nit > picking about Modula-3 syntax here and there, go about it in a > slightly different way? We're really not looking to change M3 in any way, just provide an alternate syntax. > Pick apart what defines Modula-3 through much discussion. > Optional safety -- probably but that for these purposes > optional garbage collection -- maybe that too > "object orientation" that is a subset of C++ > try to use C++ syntax? > generics (generic modules) > independently and relatively easily parsable interface definitions > (!) > these are both important, but I think "independent" is more > important > and "relatively easily" could be omitted for the goals of this > exercise > compiles to native code > sizeof(integer) == sizeof(address) (minor detail) > built in sets and good enumerations > arrays; I don't like them starting at non-zero, but enums for their > index are interesting > > Take the existing definition of C and alter it to have these > characteristics very very much like Modula-3 but with very very very > much Modula-3 syntax From darko at darko.org Tue Feb 19 11:32:22 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:32:22 +1100 Subject: [M3devel] ARM_DARWIN? Message-ID: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> I'm interested in targeting Darwin on the ARM processor, to allow software development for Apple touchscreen hardware such as the iPhone and the iPod touch. Is anyone else interested in this? I know there has been some work by others (see posts here by Iztok Kobal) on targeting processors in the ARM family. The hardware mentioned definitely runs Darwin, or something very much like it. Apparently the CPU is an ARM 11 on the iPhone. Apple is due to release an SDK shortly that will almost certainly mean there will be an ARM target in the standard (XCode) toolchain so it should be a matter of adapting Apple's back end as distributed. It would have to be a cross compiler since being hosted on the target hardware isn't very practical. I'd be very interested to hear from anyone with an interest in this platform. Regards, Darko. From jayk123 at hotmail.com Tue Feb 19 15:34:55 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 19 Feb 2008 14:34:55 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: > I would have though your input was most appropriate since your a I thought I was mostly just pissing people off.> > make assignment an expression> > no, that changes the abstract syntax, which is something we're trying > to avoid. Well.. are there no transforms allowed? Or, no growth of the abstract syntax and Modula-3 doesn't necessarily generate every node type, nor maybe does Modula-C generate every node type, but union them? For example version 1 of Modula-C probably doesn't have "objects", and maybe always unsafe, no optional safety? Though, granted, enabling you to state everything in Modula-C that you can state in Modula-3 is probably important. You don't want people chosing one or the other based on needing certain features, only based on taste. (Someone else said "Codula-3". :)) I guess maybe a more important useful angle here is the interop with C headers. VAR parameters..are roughly just pointers, ok. Or like C++ references. btw, while we are on the subject..I like C's looping constructs, the three expression for loop, do, while, break, continue. Is "exit" what I use in Modula-3 for break? I've been writing loops that could terminate once they find something but have to look this up, otherwise have been letting the loop run longer than necessary..which I saw existing code do anyway. - Jay > CC: wagner at elegosoft.com; m3devel at elegosoft.com> From: darko at darko.org> To: jayk123 at hotmail.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> Date: Tue, 19 Feb 2008 21:04:09 +1100> > I agree that there should be a pre-processor between M3 syntax and C > syntax, but this should also be integrated into the build system so > that it is transparent. I think the '.mc' extension is already taken > though, which is a bummer.> > I think we should also be aiming to use this tool to automatically > convert C header files (with limitations) to M3.> > The more I think about it the more I wonder if C programers will > swallow it: for example VAR params?> > Further comments are embedded...> > On 18/02/2008, at 3:26 PM, Jay wrote:> > I've been trying to stay out of this...> > I would have though your input was most appropriate since your a > member of the target audience.> > > If a comment at the top of the file can make the Modula-3 syntax > > more like C then..> > Not really what we're aiming for. We're looking for a separate C like > syntax in separate files.> > > replace = with ==> > yes> > > replace := with => > yes> > > make assignment an expression> > no, that changes the abstract syntax, which is something we're trying > to avoid.> > > lowercase the keywords> > yes> > > try to make braces work (with some alteration for C)> > yes> > > use type name instead of name : type> > yes> > > separate function parameters with commas and require each to state > > its type> > yes> > > for that matter, subset C and require all declarations be separate > > like that?> > Do you think C programmers would object?> > > put back ++, --, -=, +=, etc.> > yes> > > superset C and let . be used in place of ->> > yes> > > new coding style is four space indent with opening braces on their > > own line :)> > I don't do that even in C> > > Hm. I think if anyone really wants to do this, instead of nit > > picking about Modula-3 syntax here and there, go about it in a > > slightly different way?> > We're really not looking to change M3 in any way, just provide an > alternate syntax.> > > > Pick apart what defines Modula-3 through much discussion.> > Optional safety -- probably but that for these purposes> > optional garbage collection -- maybe that too> > "object orientation" that is a subset of C++> > try to use C++ syntax?> > generics (generic modules)> > independently and relatively easily parsable interface definitions > > (!)> > these are both important, but I think "independent" is more > > important> > and "relatively easily" could be omitted for the goals of this > > exercise> > compiles to native code> > sizeof(integer) == sizeof(address) (minor detail)> > built in sets and good enumerations> > arrays; I don't like them starting at non-zero, but enums for their > > index are interesting> >> > Take the existing definition of C and alter it to have these > > characteristics very very much like Modula-3 but with very very very > > much Modula-3 syntax> > > > > > _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 19 15:39:37 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 19 Feb 2008 14:39:37 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: I have some ideas here that I am pretty certain WILL be acceptable. But I'd like to know if the current behavior really isn't. The ideas are: 1) (* A well designed approach might look like this, however how do we determine the target behavior? Seps_t = RECORD (* Whenever a character must be "written", DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep : CHAR; DirSepText : TEXT; END; SepKind_t = { Unix, Win, Winx }; CONST Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; *) and then I think m3middle would have to specify the behavior of each target -- of course most are "Unix". 2) less work for now, very much like the current behavior, except Colon changes from CONST to VAR and is ':' if the environment variable OS == "Windows_NT", else '\000'. The support for backslashes could key off this too, though I believe it is FAR less controversial. Also, I want to move m3path.m3 into a lower layer so it useable a little more. Like into m3quake (QPath?) or m3middle (M3Path?). However I worry about the effect on source control history. Advise? For now I've got one path function in one m3quake file, another path function in another m3quake file, and everything else remaining in cm3/src/M3Path.m3. - Jay From: jayk123 at hotmail.comTo: mika at async.caltech.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 18 Feb 2008 22:27:56 +0000 I'm going to work on this more but not today.I will at least restrict it to check that the next character is a slash.I'm not sure that will satisfy folks.The Pathname module is/was being used but is a little unsatisfactory. > I use colons in filenames a lot Do you use it in source files?For "root" directories, like where your cm3 install/source is? I'm trying to think/wiggle through what might be an acceptable escape.Something like -- where files in general are vs. where "programmer" files are.Putting a colon in a filename really is quite non-portable.And that may or may not matter. The existing Modula-3 code was fairly strict and I very unsure it was right.I had a question drafted to m3devel that I ended up not sending.It went roughly like:" Has anyone done a cross build where host and target vary in naming conventions? I am skeptical that this works, and am strongly considering /slightly/ depending on that or making it "worse". In particular, there is provision in the code for "converting" between host and target paths, but all it does is translate slashes. It doesn't translate libfoo.a to foo.lib for example." Upon further digging though, I decide that my more immediate severe problemcould be dealt with not by making things worse but by making them better.This is the change around checking NAMING_CONVENTIONS earlier.While my analysis was not 100% thorough, it is my very strong suspicionthat the NAMING_CONVENTION and undocumented TARGET_NAMING configurationvariables never really worked. Sure, they affected the name of the .m3x file.But that is about it. I didn't check .exes, but probably didn't work, and what I wasseeing was they didn't work for libraries. M3Path.m3 sets up one set of path data in three ways. variable initialization (VAR foo := 123) module initialization (BEGIN foo := 456 END Module.) and explicit calls after reading the config file The problem was that the explicit calls were very late, so the module initialization is what held.If Join(a,b) == a/b, then you'd get Unix naming conventions./Arguably/ this is exactly correct.But I would like the slash and the "naming" to be separate, at least for now.That is, NT386GNU uses forward slashes but foo.lib instead of libfoo.a.I should try to change that actually.I had trouble changing it for this reason since I was cross building from NT386. The NT386 HOST wants to use Win32 naming conventions, "\" and foo.lib, evenif the config file asks for Unix naming.. Anyway, this is all somewhat of a tangent, one in which I'm more confident of where to go and that what I changed is ok. (It might become irrelevant.) The other issues are around "difficulty" setting paths.I had CM3_ROOT=c:\dev2\cm3.2.That wouldn't necessarily work with NT386GNU. It seems darn near possible to have one path syntax and one set of code for dealing with it.But maybe not.Even semicolon vs. colon seems doable. Specifically, if an element of $PATH appears to be just a single character, that colon is not a $PATH divider. Perhaps I just need to have two sets of CM3_ROOT / CM3_INSTALL and perhaps M3CONFIG variables.I was kind of hoping not. It's worse than that really, since the two hosts can target the two targets, so host and target paths needs to be better distinguished than I believe the are now. I was saying there is code to change the slashes, but there isn't code to deal with a leading drive letter. What I have been particularly avoiding is calls out to cygwin_convert_path or such, but maybe that's what I need to do. Get ROOT / CM3_INSTALL etc. from the command line and environment, convert as appropriate, and move on. ROOT in particular is set by Python. Usually for me that is Win32 Python, but Cygwin Python is an option.So then Python has to know what cm3 it is running?I considered probing it with findstr /i /m cm3.exe cygwin1.dll.I considered something like cm3 -report_something_or_other, kind of like gcc has -print-gcc-lib-name or whatnot. These might still be viable ideas. Historically cross environments don't allow multiple "targets" / "platforms" / "configurations" / "whatever" to run on the same OS. But there is some of an opposite trend. Like how NT386 and NT386GNU run on the same OS. Like SOLsun, SOLgnu. Like x86 on AMD64 operating systems. So maybe a little bit of support is good there, the cm3 -print-slash or cm3 -print-host or something. Also I forgot to point out that Win32 is often find with forward slashes, but notable file.open dialogs are not.I very frequently copy compiler output to file.open dialogs so in some places backward slashes are preferred.A possible strategy is to sniff what the user is using -- such as in any of those environment variables -- and favor it.Or for each Join operating harvest a path separater from the parameters and default if there is none there. I have some code working like that last option right now but it's not quite working and has to wait. It is very reasonable to have Win32 treat forward and backward slashes as the same, in particular.It is fairly reasonable imho for Posix code to also treat them the same but "fixup" backward to forward. As well, on Windows, if you mostly limit yourself to one drive letter, then /foo/bar is a pretty acceptable form.. Anyway...lots of facts, some easy conclusions, some unclear conclusions.I'll fiddle around with it more later.Ideally switching between NT386 and NT386GNU is fairly easy.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 18 Feb 2008 14:04:06 -0800> From: mika at async.caltech.edu> > > I never tried putting it in my PATH, no... You are right, colons> are *slightly* special. I am not in the habit of copying files to> Windows. I only copy files between Unix and Windows to save them> from Windows.> > That being said, I am pretty sure I use colons more in filenames> than I use the letter "q". Could you ban the letter "q" instead? :)> > If you've gotta do it, then do it. It's just ... weird.> > I personally will probably never run into the issue. I use colons> in filenames a lot, but as a separator for various types of data> files. :.> > Is your code able to import (or duplicate...) Pathname? I would> have thought that that interface has all the necessary bits to make> paths portable...> > MIka> > Jay writes:> >--_dfd4e29a-b904-43be-8435-4824d419d270_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> But colons? Colons are not special in any way, shape, or form, on> Unix..=> >. I think "it is extremely surprising" to a Unix user if a path> >Ever try putting a path with a colon into $PATH? Does it work?> >Or copying a file with a colon in its name to a Windows system? Does it wor=> >k?> >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue=> >ss.> >=20> >As a user switching between multiple systems, this area is quite frustratin=> >g...I guess no matter what.> >Sometimes one form works, sometimes another, sometimes either, often with i=> >dentical meaning, but not always.> >These changes, and about one more, should make building NT386GNU a fair amo=> >unt easier..> >=20> >Currently it is any path with a colon in the second character.> >How about if that is further restricted to having a-z in the first characte=> >r and/or more importantly a slash in the third character?> >=20> > - Jay> >> >> > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 19 18:31:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 19 Feb 2008 12:31:23 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> Message-ID: <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> I get an error: "../src/Main.m3", line 6: Could not find a legal alignment for the packed type. for the type: TYPE T = RECORD a: BITS 8 FOR [0..255]; c: BITS 16 FOR [0..65535]; b: BITS 32 FOR INTEGER; END; Are you saying that lazy alignment permits this to compile? This is very scary! What happens if you write the following? TYPE T = RECORD a: BITS 8 FOR [0..255]; c: BITS 16 FOR [0..65535]; b: BITS 32 FOR ROOT; END; Now b is a *hidden* reference (because it is unaligned) that the garbage collector will not find if T describes a stack variable t: PROCEDURE p (x: ROOT) = VAR t: T; BEGIN t.b := x; x := NIL; ... garbage collector runs and moves object referred to by t.b but doesn't find t.b reference in stack! t.b^ causes chaos and destruction... END p; Thus, lazy alignment should only be permitted in UNSAFE modules. I hope that this is the case! On Feb 19, 2008, at 5:02 AM, Darko wrote: > There wouldn't be any explicit expression. in the source, but there > would be a flag in Target.i3 for turning it off and on for > different platforms. > > Although the details may be a bit off, the principal is this: > > before byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 32 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 32 bits *) > END; > > after byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 8 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 16 bits *) > END; > > > On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > >> Thanks for the explanation! How does one express the alignment >> you support? >> >> It does sound like <*LAZYALIGN*> can go away. >> >> On Feb 18, 2008, at 8:44 PM, Darko wrote: >> >>> Actually rather than compilain rather grumpily, maybe I can just >>> make the >>> changes required to RTTipe and do the work to reomve the pragma. >>> I can >>> work with Randy to ensure it doesn't break pickles, there is no >>> reason why >>> it should. >>> >>> On tha subject Randy, I assume pickles encode the number of BITS FOR >>> for a field? If not it should. >>> >>> >>>> We seem to be going through these same point several times. I'm >>>> not sure >>>> what the difficulty is, I'm just repeating myself. >>>> >>>> Keep in mind this applies *only* to packed structures, ie BIT >>>> FOR or bit >>>> fields. >>>> >>>> The change I put in libralised the *M3* alignment rules so that >>>> BITS FOR >>>> fields in structures would align on byte boundries if possible >>>> instead of >>>> restricting them to word alignment generally. GCC happily >>>> generates code >>>> for this. There may be restrictions in GCC's C as to how you can >>>> arrange >>>> bit fields but I don't see what they have to do with M3. >>>> >>>> This is absolutely essentail for using the native APIs on Mac OS >>>> X and its >>>> removal would make M3 pointless for use on the Mac, at least >>>> more me. >>>> >>>> This should be the default behviour. If you are using BITS FOR it's >>>> becuase you want to arrange the fields in a record in particular >>>> way. Why >>>> then arbitrarliy pad out the fields? If performance is an issue, >>>> the user >>>> should be using appropriate field bit sizes. The implementation >>>> rule for >>>> BITS FOR in M3 is implementation dependent, there are no >>>> language issues. >>>> >>>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>>> created and had nothing to do with me. I diagreed with it and >>>> never used >>>> it in the version of the compiler I ran. I support its removal. >>>> >>>> >>>> >>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>> >>>>>> The alignment behaviour is absolutely crucial to programming >>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>> for it. >>>>>> >>>>>> The PRGAMA is of no use and can be removed. >>>>>> >>>>>> Does anyone have any objections to making this alignment >>>>>> behaviour >>>>>> standard? >>>>> >>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>>> the standard gcc-backend alignment? Perhaps I don't understand >>>>> what >>>>> it is you are doing or trying to do. Again, please remind me >>>>> what it >>>>> is that LAZYALIGN does and why it is needed. >>>>> >>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>> >>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>> with >>>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>>> argue to abandon it. >>>>>>> >>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>> >>>>>>>> I use pickles extensively and they are used also by network >>>>>>>> objects. >>>>>>>> I've never used LAZYALIGN. >>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>> add >>>>>>>> support for something that is rarely used. >>>>>>>> Regards, >>>>>>>> Randy >>>>>>>> >>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>> PM >>> >>>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>> without >>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>> existing >>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>> >>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>> pickles >>>>>>>> or compiled code were invalidated by a change? >>>>>>>> >>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>> variables of that type. >>>>>>>> >>>>>>>> Olaf Wagner wrote: >>>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>> LAZYALIGN. >>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>> pickles. >>>>>>>>> >>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>> >>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>>> BITSIZE, >>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>> executing >>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>> >>>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>>> both as >>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>> that >>>>>>>> wrote >>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>> generates is >>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>> field >>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>> builtin >>>>>>>> types). >>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>> >>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>> machine >>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>> description and >>>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>>> as they >>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>> the latter, >>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>> stored in the >>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>> techniques >>>>>>>>>> like >>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>> m3core, and >>>>>>>>>> called by Pickle code. >>>>>>>>>> >>>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>>> layout >>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>> involve >>>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>>> data >>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>> kind >>>>>>>> of bit >>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>> >>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>> comparing the >>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>> compiler. The >>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>> >>>>>>>>>> Note that all this is required even without any packing of >>>>>>>> small fields >>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>> pickled >>>>>>>> on a >>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>> >>>>>>>>>> Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Rodney, >>>>>>>>>>> >>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>> RTPacking? I >>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>> anyway. >>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>> figure >>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>> INTEGER is >>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>> missing >>>>>>>>>>> something? >>>>>>>>>>> >>>>>>>>>>> -- Tony >>>>>>>>>>> >>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>>> help with? >>>>>>>>>>>> >>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>> recently) >>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>> >>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>> interrupted. >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> ---------------------------------------------------------- >>>>>>>>>>>>> --- >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 darko at darko.org Tue Feb 19 21:23:23 2008 From: darko at darko.org (Darko) Date: Wed, 20 Feb 2008 07:23:23 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> Message-ID: Thanks for raising a very good point. I'd say make it that traced references will not be non-word aligned as a part of the alignment behaviour. On 20/02/2008, at 4:31 AM, Tony Hosking wrote: > I get an error: > > "../src/Main.m3", line 6: Could not find a legal alignment for the > packed type. > > for the type: > > TYPE > T = RECORD > a: BITS 8 FOR [0..255]; > c: BITS 16 FOR [0..65535]; > b: BITS 32 FOR INTEGER; > END; > > Are you saying that lazy alignment permits this to compile? > > > This is very scary! What happens if you write the following? > > TYPE > T = RECORD > a: BITS 8 FOR [0..255]; > c: BITS 16 FOR [0..65535]; > b: BITS 32 FOR ROOT; > END; > > Now b is a *hidden* reference (because it is unaligned) that the > garbage collector will not find if T describes a stack variable t: > > PROCEDURE p (x: ROOT) = > VAR t: T; > BEGIN > t.b := x; > x := NIL; > ... > garbage collector runs and moves object referred to by t.b but > doesn't find t.b reference in stack! > t.b^ causes chaos and destruction... > END p; > > Thus, lazy alignment should only be permitted in UNSAFE modules. I > hope that this is the case! > > On Feb 19, 2008, at 5:02 AM, Darko wrote: > >> There wouldn't be any explicit expression. in the source, but there >> would be a flag in Target.i3 for turning it off and on for >> different platforms. >> >> Although the details may be a bit off, the principal is this: >> >> before byte alignment change: >> >> RECORD >> a: BITS 8 FOR 0..255; (* takes 32 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >> END; >> >> after byte alignment change: >> >> RECORD >> a: BITS 8 FOR 0..255; (* takes 8 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >> END; >> >> >> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >> >>> Thanks for the explanation! How does one express the alignment >>> you support? >>> >>> It does sound like <*LAZYALIGN*> can go away. >>> >>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>> >>>> Actually rather than compilain rather grumpily, maybe I can just >>>> make the >>>> changes required to RTTipe and do the work to reomve the pragma. >>>> I can >>>> work with Randy to ensure it doesn't break pickles, there is no >>>> reason why >>>> it should. >>>> >>>> On tha subject Randy, I assume pickles encode the number of BITS >>>> FOR >>>> for a field? If not it should. >>>> >>>> >>>>> We seem to be going through these same point several times. I'm >>>>> not sure >>>>> what the difficulty is, I'm just repeating myself. >>>>> >>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>> FOR or bit >>>>> fields. >>>>> >>>>> The change I put in libralised the *M3* alignment rules so that >>>>> BITS FOR >>>>> fields in structures would align on byte boundries if possible >>>>> instead of >>>>> restricting them to word alignment generally. GCC happily >>>>> generates code >>>>> for this. There may be restrictions in GCC's C as to how you can >>>>> arrange >>>>> bit fields but I don't see what they have to do with M3. >>>>> >>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>> X and its >>>>> removal would make M3 pointless for use on the Mac, at least >>>>> more me. >>>>> >>>>> This should be the default behviour. If you are using BITS FOR >>>>> it's >>>>> becuase you want to arrange the fields in a record in particular >>>>> way. Why >>>>> then arbitrarliy pad out the fields? If performance is an issue, >>>>> the user >>>>> should be using appropriate field bit sizes. The implementation >>>>> rule for >>>>> BITS FOR in M3 is implementation dependent, there are no >>>>> language issues. >>>>> >>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>> Olaf >>>>> created and had nothing to do with me. I diagreed with it and >>>>> never used >>>>> it in the version of the compiler I ran. I support its removal. >>>>> >>>>> >>>>> >>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>> >>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>> for it. >>>>>>> >>>>>>> The PRGAMA is of no use and can be removed. >>>>>>> >>>>>>> Does anyone have any objections to making this alignment >>>>>>> behaviour >>>>>>> standard? >>>>>> >>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>> with >>>>>> the standard gcc-backend alignment? Perhaps I don't understand >>>>>> what >>>>>> it is you are doing or trying to do. Again, please remind me >>>>>> what it >>>>>> is that LAZYALIGN does and why it is needed. >>>>>> >>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>> >>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>> with >>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>> would >>>>>>>> argue to abandon it. >>>>>>>> >>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>> >>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>> objects. >>>>>>>>> I've never used LAZYALIGN. >>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>> add >>>>>>>>> support for something that is rarely used. >>>>>>>>> Regards, >>>>>>>>> Randy >>>>>>>>> >>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>> PM >>> >>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>> to >>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>> without >>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>> existing >>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>> >>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>> >>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>> variables of that type. >>>>>>>>> >>>>>>>>> Olaf Wagner wrote: >>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>> the >>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>> LAZYALIGN. >>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>> pickles. >>>>>>>>>> >>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>> >>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>> Using >>>>>>>>> BITSIZE, >>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>> executing >>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>> >>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>> type >>>>>>>>> both as >>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>> that >>>>>>>>> wrote >>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>> generates is >>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>> field >>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>> builtin >>>>>>>>> types). >>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>> >>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>> machine >>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>> description and >>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>> both >>>>>>>>> as they >>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>> the latter, >>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>> stored in the >>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>> techniques >>>>>>>>>>> like >>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>> m3core, and >>>>>>>>>>> called by Pickle code. >>>>>>>>>>> >>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>> compiler's >>>>>>>>> layout >>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>> involve >>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>> different >>>>>>>>> data >>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>> kind >>>>>>>>> of bit >>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>> >>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>> comparing the >>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>> compiler. The >>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>> >>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>> small fields >>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>> pickled >>>>>>>>> on a >>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Rodney, >>>>>>>>>>>> >>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>> RTPacking? I >>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>> anyway. >>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>> figure >>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>> INTEGER is >>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>> missing >>>>>>>>>>>> something? >>>>>>>>>>>> >>>>>>>>>>>> -- Tony >>>>>>>>>>>> >>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>> can >>>>>>>>> help with? >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>> type >>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>> recently) >>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 Feb 21 11:42:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 11:42:25 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Quoting Jay : > I have some ideas here that I am pretty certain WILL be acceptable. > But I'd like to know if the current behavior really isn't. > > The ideas are: > 1) > (* A well designed approach might look like this, however how do > we determine the target behavior? > Seps_t = RECORD (* Whenever a character must be "written", > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > : CHAR; DirSepText : TEXT; END; > SepKind_t = { Unix, Win, Winx }; > > CONST > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; > *) > and then I think m3middle would have to specify the behavior of each > target -- of course most are "Unix". > > 2) less work for now, very much like the current behavior, except > Colon changes from CONST to VAR and is ':' if the environment > variable OS == "Windows_NT", else '\000'. The support for > backslashes could key off this too, though I believe it is FAR less > controversial. > > Also, I want to move m3path.m3 into a lower layer so it useable a > little more. > Like into m3quake (QPath?) or m3middle (M3Path?). > > However I worry about the effect on source control history. > Advise? > > For now I've got one path function in one m3quake file, another path > function in another m3quake file, and everything else remaining in > cm3/src/M3Path.m3. I agree that we should have one central abstraction of the pathanme type. What about pushing it further into libm3/.../Pathname? This would need carefully checking of compatibility of course. Also I wouldn't like to see variables exposed in such a module; we should use functions or procedures for everything there. Do you see any problem in providing such a globally unique and compatible abstraction? Could you provide a complete (documented) Pathname module that could be discussed on this list and tested by everybody interested? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 11:55:05 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 21 Feb 2008 02:55:05 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Mon, 18 Feb 2008 23:52:26 EST." <47BA1A35.1E75.00D7.1@scires.com> Message-ID: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> Ugh!!! I am still using compilers that are almost ten years old on ALL my systems just because I need to share pickles between them and CM3 has a different TEXT format from my ancient PM3. Tony thinks there's a workaround with specials but I haven't had a chance to get to it yet... "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part6F499F9A.2__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Sorry, but I've never checked to see how pickles represent "BITS FOR". >I've used BITS FOR only on rare occasion. >=20 >My concern about "breaking" is that if a change is made to the encoding of = >pickles, then all other programs that use pickles would need to be rebuilt = >in order to remain compatible. I seem to recall that there is a version = >number that is put into the encoding to help with compatibility and of = >course we already have pickle, pickle2, netobj, and netobj2. Perhaps your = >change could be structured in such a way as to still understand the older = >variants for compatibility. >=20 >Here is a scenario: Suppose I have a program that uses pickles and/or = >netobj. A version is built and put into an embedded system. This system = >shares pickles/netobj with another client program. After the embedded = >system is fielded, a change is made to the encoding of pickles. New = >features are added to the client program and it is rebuilt. Now the = >client program can't share pickles with the embedded system. >=20 >Scenario2: A program uses pickles to store data in files. If the pickle = >structure is changed, the program will no longer be able to read its old = >files without some sort of transformation function on all the files. >=20 >Regards, >Randy From lemming at henning-thielemann.de Thu Feb 21 13:22:50 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Feb 2008 13:22:50 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: On Tue, 19 Feb 2008, Darko wrote: > I agree that there should be a pre-processor between M3 syntax and C > syntax, but this should also be integrated into the build system so > that it is transparent. I think the '.mc' extension is already taken > though, which is a bummer. > > I think we should also be aiming to use this tool to automatically > convert C header files (with limitations) to M3. You won't be happy with such conversions. The results of translations with SWIG using manual annotations are better, but you quickly run into writing more annotation than converting the C header manually. From darko at darko.org Thu Feb 21 13:48:17 2008 From: darko at darko.org (Darko) Date: Thu, 21 Feb 2008 23:48:17 +1100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: I find converting C headers manually not too bad using a few standard regexes and a couple of rules of thumb. I was hoping something like this could be done with exceptions handled manually. I don't think complete automatic conversion is practical as you say, but there must be something better and more productive than manual conversions. On 21/02/2008, at 11:22 PM, Henning Thielemann wrote: > > On Tue, 19 Feb 2008, Darko wrote: > >> I agree that there should be a pre-processor between M3 syntax and C >> syntax, but this should also be integrated into the build system so >> that it is transparent. I think the '.mc' extension is already taken >> though, which is a bummer. >> >> I think we should also be aiming to use this tool to automatically >> convert C header files (with limitations) to M3. > > You won't be happy with such conversions. The results of > translations with > SWIG using manual annotations are better, but you quickly run into > writing > more annotation than converting the C header manually. From jayk123 at hotmail.com Thu Feb 21 13:56:34 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 21 Feb 2008 12:56:34 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: "Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix. And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong. That is, "cleanup" of a/./b to a/b, a/../b to b. Incorrect in the face of links. But still general purpose if people want it. The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target". This is specially just changing slashes around. It does not deal with "drive letters". It deals with "file types". This is an area that probably does not belong in libm3. "types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib. There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix. Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward. It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data. As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo but when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Feb 21 14:39:21 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Feb 2008 14:39:21 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: On Thu, 21 Feb 2008, Darko wrote: > I find converting C headers manually not too bad using a few standard > regexes and a couple of rules of thumb. I was hoping something like > this could be done with exceptions handled manually. I don't think > complete automatic conversion is practical as you say, but there must > be something better and more productive than manual conversions. You can try to improve the attempts I contributed to SWIG. From dragisha at m3w.org Thu Feb 21 17:08:04 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 21 Feb 2008 17:08:04 +0100 Subject: [M3devel] Building minimal and fresh cm3... Message-ID: <1203610084.11244.14.camel@hias.m3w.org> I am trying to make minimal binary rpm for latest cm3. I am creating it's contents with: *** copied and edited cm3.cfg for new root. Set M3CONFIG to point to it. *** copied cm3cg into new .../bin (Do I need ONLY these three files for bootstrap only??? cm3, cm3cg and cm3.cfg) *** checked out yesterday's head *** did ./scripts/do-cm3-std.sh buildship At this moment, I would like to bootstrap new compiler. I see there's "sysutils" package now, so probably I have to modify former list of packages, and I did it so I typed: *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; cm3 -ship) All went well, except I had to add m3objfile (and later m3back) because of: "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/m3makefile", line 24: quake runtime error: unable to open "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading I supposse I also have to build m3cc so I have latest cm3cg? *** did ./scripts/do-cm3-std.sh buildship so all is build with latest cm3. Is this all I need to have brand new hierarchy I can pack into rpm and distribute? dd -- Dragi?a Duri? From wagner at elegosoft.com Thu Feb 21 17:48:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 17:48:30 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> Quoting Jay : > I'd like to make "progress" on what I have -- mainly slash > independence, no colon hack on Unix. > And then see about making much more progress. OK. > M3Path compromises a few bits of functionality, some of which could > go in libm3, but not all. > > It has "path cleanup", of a sort that was strongly suggested here to > be wrong. > That is, "cleanup" of a/./b to a/b, a/../b to b. > Incorrect in the face of links. > But still general purpose if people want it. > The code that does this work I think can stand a rewrite. It is > currently limited to 31 slashes and after that it just silently > ignores stuff. If you reverse the path first, do the work, reverse > again, you can support unlimited lengths with small fixed memory > (smaller than it currently uses to support limit lengths). > > It has "path conversion" between "host" and "target". > This is specially just changing slashes around. > It does not deal with "drive letters". I see. This could be abstracted, too, though. > It deals with "file types". > This is an area that probably does not belong in libm3. > "types" are, you know, .m3, .i3, reasonably simple, but also > libfoo.a vs. foo.lib. > There is code to pick apart paths to "in that way", which I find..a > little unusual. OK. This is rather compiler specific. > I did already change the Win32 Pathname implementation to > always/usually treat forward and backward slashes as the same. That > goes pretty far. > > I believe the Pathname abstraction is that a path is essentially an > array of strings, you can add/remove from either end, add to one or > the other or both ends, and join two. Yes, but it could be extended. There is also some support for different kinds of `roots'. > An issue I'm avoiding..because I don't want to pollute the code with > calls out ot Cygwin, is "correct" conversion between Win32 and > Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. > > I haven't seen how "network paths" are handled. > > Path handling is a surprisingly large rats nest of subtle behaviors > and I'm not sure I really want to open it. I'll second that. > Really, there are a few Win32 behaviors that i haven't gotten into.. > > Even if you ignore Win32 -- what about case sensitivity? Even on Mac > and presumably Unix (to a Mac or Windows server), you can encounter > case insensitive file systems. The current Modula-3 code is not > prepared for that. Case sensitivity of file names should be handled centrally, too. It could be a property of a filename. But then that property needs to be set by someone - runtime, environment, user, application... As this is a big issue for portability of code, I'd say we should come up with some sound concept here, but of course that can be independent of your current work. > One of my favorite sob stories here, I've probably told it here, is > that I have a low end NAS (it won't boot lately..). It runs Linux, > of course (I said it is low end). I downloaded it source, extracted > it, xcopied, xcopyied it again incrementally. That fails. Because > some of the file names start with a dot and on Unix, that means they > are hidden and cannot be unhidden.. `Hidden' on Unix usually only means that files are not shown with a simple `ls'. There's nothing special in the system to treat dot-files different from others as far as I know. > So this whole "hidden" thing is not portable, just as colons in > paths are not portable, but they work just fine if you stay on one > system... > Let me get M3Path to where I want it, and repair the Unix colon > behavior, and see about rewriting the "cleanup" code... as long as > folks are happy with how it ends up, I'm not sure I want to puruse > it much more. There are much bigger fish... OK, I can understand that you just want to finishd your current work. > Oh, I already have code on my system so that when we read ROOT, > CM3_INSTALL, CM3_ROOT from the command line and/or environment, > those paths get "fixed up" -- slashes reversed. That should help a > lot here, without much pollution.. It should help, but it also needs to be tested on different platforms. > One thing I'm not sure about is the treatment of backward slashes > equivalent to forward slashes on Posix. > Maybe better just to do that fixup upon a few certain inputs. And > have Win32 use either, but Posix only forward. > It's "harmless" but loose. Yes, I'd be rather conservative there, too. > There this general problem of "user input" vs. "internal, strongly > typed, analyzed, rule-following" data. > As well as then presenting the internal data back to the user in the > form he expected. > > It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo > but when an error message is reported, in case I am going to > copy/paste the paths in it to file.open, it should be back with > backward slashes. This is not simple. You could maintain two > parallel representations as you muck with the path. Not great. You > could "characterize" the form of the user in put (which slash > directory), keep that around, it's just one bit, and use it to guide > the later presentation... One internal, abstract representation of the data, and two or more views on it (getPosixPath, getWindowsPath, ...) come to mind here. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 18:25:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:25:35 -0500 Subject: [M3devel] ARM_DARWIN? In-Reply-To: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> References: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> Message-ID: I am interested, though I don't have any immediate need. On Feb 19, 2008, at 5:32 AM, Darko wrote: > I'm interested in targeting Darwin on the ARM processor, to allow > software development for Apple touchscreen hardware such as the > iPhone and the iPod touch. Is anyone else interested in this? I > know there has been some work by others (see posts here by Iztok > Kobal) on targeting processors in the ARM family. > > The hardware mentioned definitely runs Darwin, or something very > much like it. Apparently the CPU is an ARM 11 on the iPhone. > > Apple is due to release an SDK shortly that will almost certainly > mean there will be an ARM target in the standard (XCode) toolchain > so it should be a matter of adapting Apple's back end as > distributed. It would have to be a cross compiler since being > hosted on the target hardware isn't very practical. > > I'd be very interested to hear from anyone with an interest in this > platform. > > Regards, > Darko. From hosking at cs.purdue.edu Thu Feb 21 18:44:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:44:00 -0500 Subject: [M3devel] Building minimal and fresh cm3... In-Reply-To: <1203610084.11244.14.camel@hias.m3w.org> References: <1203610084.11244.14.camel@hias.m3w.org> Message-ID: Yes, a number of packages got added to the minimal distro. I would have preferred to avoid m3objfile and m3back since they are (currently) only for Windows targets, but they may become more useful on other x86 platforms in future. On Feb 21, 2008, at 11:08 AM, Dragi?a Duri? wrote: > I am trying to make minimal binary rpm for latest cm3. I am creating > it's contents with: > > *** copied and edited cm3.cfg for new root. Set M3CONFIG to point > to it. > > *** copied cm3cg into new .../bin (Do I need ONLY these three files > for > bootstrap only??? cm3, cm3cg and cm3.cfg) > > *** checked out yesterday's head > > *** did ./scripts/do-cm3-std.sh buildship > > At this moment, I would like to bootstrap new compiler. I see there's > "sysutils" package now, so probably I have to modify former list of > packages, and I did it so I typed: > > *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker > m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; > cm3 -ship) > > All went well, except I had to add m3objfile (and later m3back) > because > of: > > "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/ > m3makefile", > line 24: quake runtime error: unable to open > "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading > > I supposse I also have to build m3cc so I have latest cm3cg? > > *** did ./scripts/do-cm3-std.sh buildship so all is build with latest > cm3. > > Is this all I need to have brand new hierarchy I can pack into rpm > and > distribute? > > dd > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Thu Feb 21 18:54:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:54:54 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> Message-ID: I will dip my toe into this swamp only to make some high-level observations. First, until we can come up with a well-specified abstraction in the form of a clean M3 interface I for one will find it increasingly difficult to follow the motivation and developments of any scheme. In the face of that difficulty, I strongly prefer to stick to the current, non-portable, approach (ie, different path encodings for different targets maintained *separately*). This will minimize disturbance for the many of us that only work on POSIX targets and need those to stay stable. I am very nervous that my POSIX target will start to behave strangely or differently because of some interim commit to a rapidly evolving code base. Hence, I applaud Olaf's suggestion that we come up with a clean design before we start hacking, and that the implementation stay off the critical path until it has been well-tested and understood. On Feb 21, 2008, at 11:48 AM, Olaf Wagner wrote: > Quoting Jay : >> I'd like to make "progress" on what I have -- mainly slash >> independence, no colon hack on Unix. >> And then see about making much more progress. > > OK. > >> M3Path compromises a few bits of functionality, some of which >> could go in libm3, but not all. >> >> It has "path cleanup", of a sort that was strongly suggested here >> to be wrong. >> That is, "cleanup" of a/./b to a/b, a/../b to b. >> Incorrect in the face of links. >> But still general purpose if people want it. >> The code that does this work I think can stand a rewrite. It is >> currently limited to 31 slashes and after that it just silently >> ignores stuff. If you reverse the path first, do the work, >> reverse again, you can support unlimited lengths with small fixed >> memory (smaller than it currently uses to support limit lengths). >> >> It has "path conversion" between "host" and "target". >> This is specially just changing slashes around. >> It does not deal with "drive letters". > > I see. This could be abstracted, too, though. > >> It deals with "file types". >> This is an area that probably does not belong in libm3. >> "types" are, you know, .m3, .i3, reasonably simple, but also >> libfoo.a vs. foo.lib. >> There is code to pick apart paths to "in that way", which I >> find..a little unusual. > > OK. This is rather compiler specific. > >> I did already change the Win32 Pathname implementation to always/ >> usually treat forward and backward slashes as the same. That goes >> pretty far. >> >> I believe the Pathname abstraction is that a path is essentially >> an array of strings, you can add/remove from either end, add to >> one or the other or both ends, and join two. > > Yes, but it could be extended. There is also some support for > different kinds of `roots'. > >> An issue I'm avoiding..because I don't want to pollute the code >> with calls out ot Cygwin, is "correct" conversion between Win32 >> and Cygwin paths. Generally the conversion is c:\foo <=> / >> cygdrive/foo. >> >> I haven't seen how "network paths" are handled. >> >> Path handling is a surprisingly large rats nest of subtle >> behaviors and I'm not sure I really want to open it. > > I'll second that. > >> Really, there are a few Win32 behaviors that i haven't gotten into.. >> >> Even if you ignore Win32 -- what about case sensitivity? Even on >> Mac and presumably Unix (to a Mac or Windows server), you can >> encounter case insensitive file systems. The current Modula-3 >> code is not prepared for that. > > Case sensitivity of file names should be handled centrally, too. > It could be a property of a filename. But then that property needs to > be set by someone - runtime, environment, user, application... > As this is a big issue for portability of code, I'd say we should > come up with some sound concept here, but of course that can be > independent of your current work. > >> One of my favorite sob stories here, I've probably told it here, >> is that I have a low end NAS (it won't boot lately..). It runs >> Linux, of course (I said it is low end). I downloaded it source, >> extracted it, xcopied, xcopyied it again incrementally. That >> fails. Because some of the file names start with a dot and on >> Unix, that means they are hidden and cannot be unhidden.. > > `Hidden' on Unix usually only means that files are not shown with > a simple `ls'. There's nothing special in the system to treat dot- > files > different from others as far as I know. > >> So this whole "hidden" thing is not portable, just as colons in >> paths are not portable, but they work just fine if you stay on >> one system... > >> Let me get M3Path to where I want it, and repair the Unix colon >> behavior, and see about rewriting the "cleanup" code... as long >> as folks are happy with how it ends up, I'm not sure I want to >> puruse it much more. There are much bigger fish... > > OK, I can understand that you just want to finishd your current work. > >> Oh, I already have code on my system so that when we read ROOT, >> CM3_INSTALL, CM3_ROOT from the command line and/or environment, >> those paths get "fixed up" -- slashes reversed. That should help >> a lot here, without much pollution.. > > It should help, but it also needs to be tested on different platforms. > >> One thing I'm not sure about is the treatment of backward slashes >> equivalent to forward slashes on Posix. >> Maybe better just to do that fixup upon a few certain inputs. And >> have Win32 use either, but Posix only forward. >> It's "harmless" but loose. > > Yes, I'd be rather conservative there, too. > >> There this general problem of "user input" vs. "internal, >> strongly typed, analyzed, rule-following" data. >> As well as then presenting the internal data back to the user in >> the form he expected. >> >> It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo >> but when an error message is reported, in case I am going to copy/ >> paste the paths in it to file.open, it should be back with >> backward slashes. This is not simple. You could maintain two >> parallel representations as you muck with the path. Not great. >> You could "characterize" the form of the user in put (which >> slash directory), keep that around, it's just one bit, and use it >> to guide the later presentation... > > One internal, abstract representation of the data, and two or more > views on it (getPosixPath, getWindowsPath, ...) come to mind here. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 19:09:13 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 19:09:13 +0100 Subject: [M3devel] Building minimal and fresh cm3... In-Reply-To: <1203610084.11244.14.camel@hias.m3w.org> References: <1203610084.11244.14.camel@hias.m3w.org> Message-ID: <20080221190913.mzepfpxvls0c4g44@mail.elegosoft.com> Why not just use scripts/make-bin-dist-min.sh? This is run nightly for all tested platforms, too. If you could add a switch to produce an rpm archive on Linux, that could be done automatically, too. Olaf Quoting Dragi?a Duri? : > I am trying to make minimal binary rpm for latest cm3. I am creating > it's contents with: > > *** copied and edited cm3.cfg for new root. Set M3CONFIG to point to it. > > *** copied cm3cg into new .../bin (Do I need ONLY these three files for > bootstrap only??? cm3, cm3cg and cm3.cfg) > > *** checked out yesterday's head > > *** did ./scripts/do-cm3-std.sh buildship > > At this moment, I would like to bootstrap new compiler. I see there's > "sysutils" package now, so probably I have to modify former list of > packages, and I did it so I typed: > > *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker > m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; > cm3 -ship) > > All went well, except I had to add m3objfile (and later m3back) because > of: > > "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/m3makefile", > line 24: quake runtime error: unable to open > "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading > > I supposse I also have to build m3cc so I have latest cm3cg? > > *** did ./scripts/do-cm3-std.sh buildship so all is build with latest > cm3. > > Is this all I need to have brand new hierarchy I can pack into rpm and > distribute? > > dd > > -- > Dragi?a Duri? > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 21:16:41 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 21 Feb 2008 15:16:41 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: <47BD95D6.1E75.00D7.1@scires.com> I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy >>> Jay 2/21/2008 7:56 AM >>> "Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix. And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong. That is, "cleanup" of a/./b to a/b, a/../b to b. Incorrect in the face of links. But still general purpose if people want it. The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target". This is specially just changing slashes around. It does not deal with "drive letters". It deals with "file types". This is an area that probably does not belong in libm3. "types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib. There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix. Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward. It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data. As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo but when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: mika at async.caltech.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > I have some ideas here that I am pretty certain WILL be acceptable. > > But I'd like to know if the current behavior really isn't. > > > > The ideas are: > > 1) > > (* A well designed approach might look like this, however how do > > we determine the target behavior? > > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END; > > SepKind_t = { Unix, Win, Winx }; > > > > CONST > > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; > > *) > > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix". > > > > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial. > > > > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more. > > Like into m3quake (QPath?) or m3middle (M3Path?). > > > > However I worry about the effect on source control history. > > Advise? > > > > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3. > > I agree that we should have one central abstraction of the pathanme > type. What about pushing it further into libm3/.../Pathname? This would > need carefully checking of compatibility of course. Also I wouldn't > like to see variables exposed in such a module; we should use > functions or procedures for everything there. > > Do you see any problem in providing such a globally unique and > compatible abstraction? > > Could you provide a complete (documented) Pathname module that could be > discussed on this list and tested by everybody interested? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Shed those extra pounds with MSN and The Biggest Loser! Learn more. ( http://biggestloser.msn.com/ ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 06:26:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 05:26:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47BD95D6.1E75.00D7.1@scires.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <47BD95D6.1E75.00D7.1@scires.com> Message-ID: I made one change to the Win32 Pathname implementation and that will be it unless there is more thought and consensus. That change is to treat forward and backward slashes "the same", essentially as the underlying layer (kernel32.dll) already does. Is this not ok? You do all realize that Win32 /largely/ accepts forward slashes just fine, right? There are some exceptions.It is the functions in kernel32.dll that accept them. Not necessarily shlwapi.dll and definitely not the file.open dialogs. There is way in which forward slashes don't work. I can explain later. M3Path currently has "strange" behavior on Posix for colon and backward slash. I have the colon and I think backslash parts fixed on my machine. Essentially I have: CONST Slash = '/'; VAR (* formerly CONST *) Backslash := '\000'; (* initial value for Posix *) Colon := '\000'; (* initial value for Posix *)IsDirSep(ch) return (ch = Slash OR ch = Backslash) IsSep(ch) return (ch = Slash OR ch = Backslash OR ch = Colon) I do actually worry about nulls in strings sometimes but nobody else seems to. Allowing nulls is an advantage of approaches that keep a length separate. I believe the previous code was already sleazy this way. BEGIN (* Module initialization *) LocalSlash := Text.GetChar ( Pathname.Join ("a", "b"), 1); IF LocalSlash = '\\' THEN BackSlash := '\\'; Colon := ':'; ELSE OS := Env.Get ("OS"); IF OS # NIL AND Text.Equal (OS, "Windows_NT") THEN same thing END END; The point being to accept colons and backslashes on NT386 and Cygwin. One thing I don't quite get and people here probably don't realize is that the compiler tries to traffice in both host and target paths. It's not just about portabily using the host system, as people are so happy with the existing libm3 for. Now, I'm not sure what the point is, and I am skeptical it even works. I think the point might be for when bootstrapping, maybe to use the .M3SHIP files on the target. This need to deal with more than just the host system's paths MIGHT be something for libm3. Some way to "sniff" a path for its type, and then deal with it using the interfaces. This is probably easily done just be exposing PathPosix and PathWin32, which implement themselves and Path. The interface could just be Path to start, plus an explicit "create" function to get started, and maybe a "get" function to get the string as a regular string. A function "FixUp" or specifically "CleanupSlashes" that changes runs of slashes to single slashes, and "RemoveSingleDots" and "RemoveDoubleDots" might be ok to provide but you'd have to call them manually. Gotta go, - Jay Date: Thu, 21 Feb 2008 15:16:41 -0500From: rcoleburn at scires.comTo: wagner at elegosoft.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy>>> Jay 2/21/2008 7:56 AM >>>"Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix.And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong.That is, "cleanup" of a/./b to a/b, a/../b to b.Incorrect in the face of links.But still general purpose if people want it.The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target".This is specially just changing slashes around.It does not deal with "drive letters". It deals with "file types".This is an area that probably does not belong in libm3."types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib.There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix.Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward.It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data.As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foobut when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 08:37:37 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 07:37:37 +0000 Subject: [M3devel] some vagaries of Win32 path semantics (and some Mac) Message-ID: some vagaries of Win32 path semantics (and some Mac) You can learn about this stuff by looking at the NT namespace with winobj.And/or watching calls to NtCreateFile in a debugger.And/or with filemon.And/or reading the documentation for driver writers.And/or various documentation about the NT kernel interface.And/or experimenting with cmd (assuming cmd isn't doing the wierd stuff). This is about kernel32.dll for now. When using 8 bit characters, the length limit is 260 characters.Whether or not that includes the terminal zero is not clear. When using 16 bit characters, the "default" limit is also 260 characters. MS-DOS limit is 64 or maybe 128 characters, so this is progress. (!) Unix limit I think is usually around 1024. That's still pretty lame imho, just a little less lame. The actual Windows limit is 32K which seems pretty ok to me, though 16bit limits are surprising. The limit on INDIVIDUAL PATH ELEMENTS, as dictated by FindFirstFile/FindNextFileis also 260 characters. But again, for individual path elements.I haven't tried exceeding that. The creation paths don't clearly havethis limit. It is worth experimenting with. Ignoring Windows 9x, everything is built on top of the NT kernel.Most interesting here is NtCreateFile. At the kernel level, "relative opens" are allowed.All the various "name" or "path" based functions don't just take a string,they take an OBJECT_ATTRIBUTES.This is mainly flags, an optional parent handle, and a unicode string.The length of the unicode string is stored in an unsigned shortrepresenting a number of bytes. So the limit is around 32,767.One of the flags controls case sensitivity, for example, at least somewhat.I don't know what happens if you try to be case sensitive on FAT, for example. NTFS allows volumes to be mounted in empty directories.I assume such a volume could be FAT, so even if c:\ is NTFS and capableof case sensitivity, c:\foo might not be. If you are doing a non-relative open at the NT level, there is no working directoryor relative paths or such. There is basically just full paths.They don't look quite exactly like anything else.They look like \??\c:\windows\system32\kernel32.dll or \??\unc\machine\share\foo\bar.txt \?? before around NT4 was named \DosDevices.I suspect \?? was an optimization -- making the common case a shorter string.Seems lame but oh well.You can see in driver stuff about setting up symbolic links related to \DosDevices. Yes, NT has symbolic links, in the kernel namespace. At the kernel32.dll level, the documentation clearly exposes something very related.To open paths longer than 260 characters, they say to use the prefixes: \\? or \\?\unc Last I checked, the documentation was a little unclear.What they mean is, to form paths like: \\?\c:\windows\system32\kernel32.dll \\?\unc\machine\share\foo\bar.txt They don't say so, but quick attempts otherwise clearly show, thatthe paths must be full paths. No relative to any "current working directory". An implementation trick should be evident.Just change the second character from \ to ? and you get an NT path. The documentation says \\? "turns off path parsing". Usually all file paths undergo some amount of canonicalization.Forward slashes are changed to backward slashes.Runs of backward slashes are changed to a single slash.Spaces might be removed in some places?Trailing dots also?That is what \\? "turns off". You can see this if you make some CreateFile calls and watch the resulting NtCreateFile.I should put together a demo. Using some hack to intercept the NtCreateFile call. Nearly everything is demoable from the command line.Try this: C:\> mkdir "foo" C:\> mkdir "foo " A subdirectory or file foo already exists. Huh? C:\>mkdir foo. A subdirectory or file foo. already exists. Huh? C:\>mkdir " foo" ok. C:\>mkdir "\\?\c:\foo"C:\>mkdir "\\?\c:\foo " => works rmdir "\\?\c:\foo " C:\>mkdir "\\?\c:\foo." C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\ 02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>rmdir foo.The system cannot find the file specified. Huh? C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\ 02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>mkdir bar. C:\>rmdir bar. C:\>mkdir bar. C:\>rmdir bar huh? mkdir "foo \bar" dir foo expands to "foo " because tab found it but then enterand File Not Found Huh? C:\>mkdir "\\?\c:\foo/" The filename, directory name, or volume label syntax is incorrect. => forward slash not liked C:\>mkdir "c:\foo/" => no error C:\>mkdir "\\?\c:\foo\..\bar" The filename, directory name, or volume label syntax is incorrect. => .. apparently not liked I tried . and that did work. C:\>mkdir c:\foo\..\bar => ok So now I ask -- what is the portable interface and implementation? Most code uses CreateFile and doesn't use \\?. So most code is limited to MAX_PATH and has problems with spaces and dots in some places. These features are all laudable -- allow paths with more than 260 characters and with spaces and dots in more places, if the programmer or user really wants, but this \\? vs. \\? behavior is strange. Trailing spaces in paths tend to be "invisible" in any user interface. (I wonder about tabs too, vertical space, beep, etc.) Note that not everything goes through Win32 usermode CreateFile/kernel32.dll. It is not the one and only path to the file system, but it is overwhelmingly common. Imagine going over the network from a non-Windows client (e.g. Samba) And maybe Services for Unix. shlwapi.dll and even shell32.dll also have a bunch of path/file unitility functions. I've hardly ever used them. I think I tried forward slashes with shlwapi.dll once and no go. In an ntsd/cdb/windbg, try a breakpoint like: bp ntdll!NtCreateFile "!obja poi(@esp+c);g" That will trace the paths to NtCreateFile. It is a low tech filemon.esp is the stack pointer and the object attributes is the third parameter (4*3=c),and !obja prints object attributes. I got bored writing this and maybe didn't finish covering everything, sorry.The thing to do is experiment and see what all changes between CreateFile and NtCreateFile.e.g. paths relative to the current working directory. Oh, also, there is a relative working directory per volume on Windows.There are special environment variables used to store them.Something like the variable =c: has c:'s working directory. C:\>echo %=c:% C:\ C:\>cd foo C:\foo>echo %=c:% C:\foo I only have one volume, so let's make another: C:\foo>subst d: c:\ d: cd bar D:\bar>echo %=d:% D:\bar c: brings me back to c:\foo cd d:\windows changes the working directory of D:, but doesn't bring me there d: now I am on the d: drive You can use /d to cd to change drive and directory at the same time. Cygwin also uses NtCreateFile sometimes. I haven't yet looked at why. NTFS has hardlinks for files, not directories (avoid cycles and I guess adequate for strict Posix?). NTFS on Vista has symlinks I guess for files and directories, not sure. Windows 2000 added a CreateHardLink function. XP has "fsutil hardlink create newlink existingfile" Vista has that and "mklink". Also, on my Mac I can create filenames with forward slashes in them.I have some old files from www.apple.com named like "C/C++ compiler reference".At the command line I think the forward slashes show as colons.Historically on the Mac the colon is path separator, but the "syntax"is different than Posix and Windows. Pathname.i3 documents it. If you read the Mac OS X overviews, you can see Mac OS X is a tremendous mish-mashof similar redundant interfaces and implementations.There are many sets of functions for doing the same thing.There are older functions for example that take 8 bit characters, with limits of255, though usually I believe you do directory relative opens. There are newer APIs that use Unicode and are more opaque. You can have two volumes with the same nameso: :hard disk:foo:bar (at least on Mac OS Classic, not sure about X)can actually name any number of files on Mac, depending on how many disks are named "hard disk". I think what you have to do is enumerate volumes, get their "reference numbers" and do relativeopens from there. so much for string equality meaning two paths reference the same file.Now, granted, if you do two open calls with the same path, I assume it always gets the same one.However, what if in the meantime, more volumes come online?Maybe earlier mounted is earlier opened and consistent? Big mess. (GS/OS on the long dead Apple IIGS also has this forward slash or colon behavior,and I think instead of one current working directory, you could assign a bunch ofthem to numbers. I think file names couldn't start with numbers, or maybe that was ambiguous.) - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 10:00:04 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 09:00:04 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47BD95D6.1E75.00D7.1@scires.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <47BD95D6.1E75.00D7.1@scires.com> Message-ID: As long as \ never occurs, no change. Even if it does..think about it. Before \ was treated as a "regular" character, allowed in paths. It is very unlikely, but not impossible, that \ ever occured, and then it is also unlikely, but not impossible, for the opens with \ to succeed at the next level down. It is more likely to have failed. And then it is very unlikely, but again not impossible, to imagine that code could be depending on this failure. Every single line changed is a change that must be thought through. The implementation is the interface. It is impossible to separate out something smaller and claim it is all other code depends on. For any given change, I can probably come up with code that it broke. If you use more memory, there could be code on the verge of running out of memory that you pushed over the edge. If you expand some limit, there could be code relying on things having smaller limits. If you make something faster, you can expose a race condition, that was already there but tending not to occur. If you make something slower, well, people will just complain. If all I do is add some new functions, well, like memory, I was almost out of disk space or more realistically virtual address space, and now I am. This is a real example. I have seen some code break just because other code grew in size. The code was arguably buggy, but that is besides the point. That doesn't mean that nothing can be changed. You just have to apply reason. So, for the case of backward slashes in Posix paths, is treating them like forward slashes dangerous?This is only in M3Path.m3, that the compiler uses. It is not in the more widely used Pathname module in libm3. I'm going to undo th change and leave it only for "NT386GNU", and I have to double double check that it helps there..well, I know it helps upon input. Imagine you have a text file with some paths and you move it across machines.. Do you: invent a new abstract "path" to store in the file, and write translation on either side ? adopt an existing form and translate on foreign systems ? adopt what looks very nearly like very system's format and be a little careful ? In the form you chose, can you represent anything that is possibly valid? Or do get a bit lazy and disallow some paths, like forward slashes (legal on Mac OS remember) ? A start to an abstract representation is an array of strings, and the strings can have any character, and they have a length stored (don't depend on either space or null termination). a "text" file format becomes less convenient now, because there is no delimiter, you have to store the length. You can still do that as text, it's just less convenient to edit. If you can get away with only storing full paths, that is probably an adequate represenation. If you want some indirection, it is probably useful to decide some "roots", some common prefixes, and factor that out somehow. But this depends on the application. And/Or maybe on the recieving end there is a "search algorithm". I'm just saying, this area is complicated, I know it is complicated. Forward slashes usually do have the same meaning on Win32 as backward slashes AND my goal here to make the system easier to use for anyone, such as myself, using NT386 and NT386GNU. I shouldn't have to set install root and the source root differently between them. Maybe this is just me and I'm lazy and I should suck it up, but if I only have one drive, the ability to use just /cm3 and /dev2/cm3.2 is so close to already being there..and furthermore...if someone is using NT386GNU, but any "normal" Windows editor (ie: not Cygwin vi/emacs), they will want errors printed out with backward slashes so they can copy/paste them into their editor. I guess the "presentation format" should be user configurable. Where "presentation format" could be limited what slash to use. Leaving the user to possibly prefix with c: or /cygdrive/c, which is at least less tedious than changing all the slashes.. That's kind of the thing -- user input and output paths should be more flexible and/or configurable than internal forms. However internal forms should not be warped much or at all to handle this, only input/output functions that mediate between the two. One form caters to various users with various tastes. One form caters to code that is simpler to have just one form and benefits not at all from other forms. The "temptation" though is to make them the same. Anyway, I have this "FixupPath" function that should basically make things this way. I maybe can remove the allowance for the different slashes anywhere else. The output issue is bothering me less right now than the input issue, and even the input issue I had mostly sucked up anyway. I think I was hitting some other problem not related to my own taste/laziness that made me revisit this. As it was, I had already "rewritten" M3Path.m3 twice and then abandoned it, figuring that the original authors had already figured this stuff out and it must already be right..but then I looked at it more and no longer thing that. I don't believe the "naming convention" declared in config files ever did much. All that determined things was the runtime probed slash that Pathname.i3 used. So, making NT386GNU use forward slashes but otherwise Windows naming conventions didn't work. I don't think, correct me if I'm wrong, I don't think libfoo.a vs. foo.lib should be tied with / vs. \. However, I also don't mind switching to libfoo.a for NT386GNU (a target I'm not likely to use once it work..). Maybe I should move on to that. Well, can't leave things as they are anyway... - Jay Date: Thu, 21 Feb 2008 15:16:41 -0500From: rcoleburn at scires.comTo: wagner at elegosoft.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy>>> Jay 2/21/2008 7:56 AM >>>"Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix.And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong.That is, "cleanup" of a/./b to a/b, a/../b to b.Incorrect in the face of links.But still general purpose if people want it.The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target".This is specially just changing slashes around.It does not deal with "drive letters". It deals with "file types".This is an area that probably does not belong in libm3."types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib.There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix.Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward.It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data.As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foobut when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 11:09:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 10:09:41 +0000 Subject: [M3devel] some vagaries of Win32 path semantics (and some Mac) Message-ID: I remembered more complications. Remember that many of these are exposed to Unix via Windows file servers. And of course Mac -- notice that PPC_DARWIN is case sensitive about names, even though that is commonly "wrong". But again, it varies per file system, not "POSIX" vs. "WIN32" ("POSIX" as in Modula-3 source directory/OS_TYPE. I don't know about the standard.) When you are case insensitive, just what are the rules? M3Path handles only a-z. And it doesn't handle Unicode anyway I think, not sure. On NTFS.. C:\>more < $UpcaseAccess is denied. C:\>more < $UpcasexThe system cannot find the file specified. C:\> http://www.ntfs.com/ntfs-system-files.htm There's also a technote on www.apple.com talking about precomposed or non-precomposed and what is canonical. This has something to do with accent characters. And short names are funky. You can turn off the generation of them. I think I sent there here already, but watch this: First, they aren't necessarily shorter than long names. In this case the short name is twice the length of the long name. Short names are always limited to 8.3 though, one dot, and certain characters (ie: not Unicode, I think). C:\>mkdir 1.1.1 C:\>dir /x 1*02/22/2008 02:03 AM 112E5D~1.1 1.1.1 Second, wildcard matching (FindFirstFile/FindNextFile) always includes them: C:\>mkdir foo.bar C:\>mkdir foo.barf C:\>dir *.bar 02/22/2008 02:04 AM foo.bar02/22/2008 02:04 AM foo.barf Huh? C:\>dir /x *bar02/22/2008 02:04 AM foo.bar02/22/2008 02:04 AM FOO~1.BAR foo.barf Oh.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: some vagaries of Win32 path semantics (and some Mac)Date: Fri, 22 Feb 2008 07:37:37 +0000 some vagaries of Win32 path semantics (and some Mac) You can learn about this stuff by looking at the NT namespace with winobj.And/or watching calls to NtCreateFile in a debugger.And/or with filemon.And/or reading the documentation for driver writers.And/or various documentation about the NT kernel interface.And/or experimenting with cmd (assuming cmd isn't doing the wierd stuff).This is about kernel32.dll for now.When using 8 bit characters, the length limit is 260 characters.Whether or not that includes the terminal zero is not clear.When using 16 bit characters, the "default" limit is also 260 characters. MS-DOS limit is 64 or maybe 128 characters, so this is progress. (!) Unix limit I think is usually around 1024. That's still pretty lame imho, just a little less lame. The actual Windows limit is 32K which seems pretty ok to me, though 16bit limits are surprising.The limit on INDIVIDUAL PATH ELEMENTS, as dictated by FindFirstFile/FindNextFileis also 260 characters. But again, for individual path elements.I haven't tried exceeding that. The creation paths don't clearly havethis limit. It is worth experimenting with.Ignoring Windows 9x, everything is built on top of the NT kernel.Most interesting here is NtCreateFile.At the kernel level, "relative opens" are allowed.All the various "name" or "path" based functions don't just take a string,they take an OBJECT_ATTRIBUTES.This is mainly flags, an optional parent handle, and a unicode string.The length of the unicode string is stored in an unsigned shortrepresenting a number of bytes. So the limit is around 32,767.One of the flags controls case sensitivity, for example, at least somewhat.I don't know what happens if you try to be case sensitive on FAT, for example.NTFS allows volumes to be mounted in empty directories.I assume such a volume could be FAT, so even if c:\ is NTFS and capableof case sensitivity, c:\foo might not be.If you are doing a non-relative open at the NT level, there is no working directoryor relative paths or such. There is basically just full paths.They don't look quite exactly like anything else.They look like \??\c:\windows\system32\kernel32.dll or \??\unc\machine\share\foo\bar.txt \?? before around NT4 was named \DosDevices.I suspect \?? was an optimization -- making the common case a shorter string.Seems lame but oh well.You can see in driver stuff about setting up symbolic links related to \DosDevices.Yes, NT has symbolic links, in the kernel namespace.At the kernel32.dll level, the documentation clearly exposes something very related.To open paths longer than 260 characters, they say to use the prefixes: \\? or \\?\uncLast I checked, the documentation was a little unclear.What they mean is, to form paths like: \\?\c:\windows\system32\kernel32.dll \\?\unc\machine\share\foo\bar.txt They don't say so, but quick attempts otherwise clearly show, thatthe paths must be full paths. No relative to any "current working directory".An implementation trick should be evident.Just change the second character from \ to ? and you get an NT path.The documentation says \\? "turns off path parsing".Usually all file paths undergo some amount of canonicalization.Forward slashes are changed to backward slashes.Runs of backward slashes are changed to a single slash.Spaces might be removed in some places?Trailing dots also?That is what \\? "turns off".You can see this if you make some CreateFile calls and watch the resulting NtCreateFile.I should put together a demo. Using some hack to intercept the NtCreateFile call.Nearly everything is demoable from the command line.Try this: C:\> mkdir "foo" C:\> mkdir "foo " A subdirectory or file foo already exists. Huh? C:\>mkdir foo. A subdirectory or file foo. already exists. Huh? C:\>mkdir " foo"ok.C:\>mkdir "\\?\c:\foo"C:\>mkdir "\\?\c:\foo " => works rmdir "\\?\c:\foo "C:\>mkdir "\\?\c:\foo."C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes freeC:\>rmdir foo.The system cannot find the file specified.Huh?C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>mkdir bar. C:\>rmdir bar. C:\>mkdir bar. C:\>rmdir bar huh? mkdir "foo \bar" dir foo expands to "foo " because tab found it but then enterand File Not Found Huh? C:\>mkdir "\\?\c:\foo/" The filename, directory name, or volume label syntax is incorrect. => forward slash not liked C:\>mkdir "c:\foo/" => no error C:\>mkdir "\\?\c:\foo\..\bar" The filename, directory name, or volume label syntax is incorrect. => .. apparently not liked I tried . and that did work. C:\>mkdir c:\foo\..\bar => ok So now I ask -- what is the portable interface and implementation? Most code uses CreateFile and doesn't use \\?. So most code is limited to MAX_PATH and has problems with spaces and dots in some places. These features are all laudable -- allow paths with more than 260 characters and with spaces and dots in more places, if the programmer or user really wants, but this \\? vs. \\? behavior is strange. Trailing spaces in paths tend to be "invisible" in any user interface.(I wonder about tabs too, vertical space, beep, etc.) Note that not everything goes through Win32 usermode CreateFile/kernel32.dll. It is not the one and only path to the file system, but it is overwhelmingly common. Imagine going over the network from a non-Windows client (e.g. Samba) And maybe Services for Unix. shlwapi.dll and even shell32.dll also have a bunch of path/file unitility functions. I've hardly ever used them. I think I tried forward slashes with shlwapi.dll once and no go.In an ntsd/cdb/windbg, try a breakpoint like: bp ntdll!NtCreateFile "!obja poi(@esp+c);g" That will trace the paths to NtCreateFile. It is a low tech filemon.esp is the stack pointer and the object attributes is the third parameter (4*3=c),and !obja prints object attributes.I got bored writing this and maybe didn't finish covering everything, sorry.The thing to do is experiment and see what all changes between CreateFile and NtCreateFile.e.g. paths relative to the current working directory.Oh, also, there is a relative working directory per volume on Windows.There are special environment variables used to store them.Something like the variable =c: has c:'s working directory. C:\>echo %=c:% C:\ C:\>cd foo C:\foo>echo %=c:% C:\foo I only have one volume, so let's make another: C:\foo>subst d: c:\ d: cd bar D:\bar>echo %=d:% D:\bar c: brings me back to c:\foo cd d:\windows changes the working directory of D:, but doesn't bring me there d: now I am on the d: drive You can use /d to cd to change drive and directory at the same time.Cygwin also uses NtCreateFile sometimes. I haven't yet looked at why. NTFS has hardlinks for files, not directories (avoid cycles and I guess adequate for strict Posix?). NTFS on Vista has symlinks I guess for files and directories, not sure. Windows 2000 added a CreateHardLink function. XP has "fsutil hardlink create newlink existingfile" Vista has that and "mklink". Also, on my Mac I can create filenames with forward slashes in them.I have some old files from www.apple.com named like "C/C++ compiler reference".At the command line I think the forward slashes show as colons.Historically on the Mac the colon is path separator, but the "syntax"is different than Posix and Windows. Pathname.i3 documents it.If you read the Mac OS X overviews, you can see Mac OS X is a tremendous mish-mashof similar redundant interfaces and implementations.There are many sets of functions for doing the same thing.There are older functions for example that take 8 bit characters, with limits of255, though usually I believe you do directory relative opens.There are newer APIs that use Unicode and are more opaque.You can have two volumes with the same nameso: :hard disk:foo:bar (at least on Mac OS Classic, not sure about X)can actually name any number of files on Mac, depending on how many disks are named "hard disk".I think what you have to do is enumerate volumes, get their "reference numbers" and do relativeopens from there.so much for string equality meaning two paths reference the same file.Now, granted, if you do two open calls with the same path, I assume it always gets the same one.However, what if in the meantime, more volumes come online?Maybe earlier mounted is earlier opened and consistent? Big mess.(GS/OS on the long dead Apple IIGS also has this forward slash or colon behavior,and I think instead of one current working directory, you could assign a bunch ofthem to numbers. I think file names couldn't start with numbers, or maybe that was ambiguous.) - Jay Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 11:41:54 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 10:41:54 +0000 Subject: [M3devel] some Cygwin path vagaries In-Reply-To: <20080222111045.2qhhuhoqo0cgo4sk@mail.elegosoft.com> References: <20080222104722.lh7jgctc68kk4wso@mail.elegosoft.com> <20080222111045.2qhhuhoqo0cgo4sk@mail.elegosoft.com> Message-ID: Well this surprised me. Cygwin fopen accepts all of /cygdrive/c/1.txt \cygdrive\c\1.txt c:\1.txt c:/1.txt They all mean the same (well, actually, that I just assume, I'm able to fopen each) c:1.txt didn't work (it would work in Win32) I thought I'd seen Cygwin not accepting Win32 paths. Geez, maybe this makes things easier.. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 22 16:24:08 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:24:08 -0600 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] Message-ID: <47BEE918.1060908@wichita.edu> This didn't appear to come through to the list the first time: -------- Original Message -------- Subject: Re: [M3devel] <*LAZYALIGN*> Date: Mon, 18 Feb 2008 20:11:17 -0600 From: Rodney M. Bates To: Randy Coleburn CC: m3devel at elegosoft.com References: <47AF72B5.2080308 at wichita.edu> <47B1168F.8020302 at wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236 at darko.org> <47B4C70D.4010408 at wichita.edu> <7323567C-7632-4040-B858-47B8124759DC at cs.purdue.edu> <47B50EDF.8060807 at wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843 at cs.purdue.edu> <47B5FB13.7070407 at wichita.edu> <20080215223205.t9a01icx4okgco0o at mail.elegosoft.com> <47B60CE0.8050506 at wichita.edu> <47B9644F.1E75.00D7.1 at scires.com> Just to clarify: I don't believe anything existing has to break. The worst scenario I can see is that you would have to either simultaneously upgrade the compiler, libm3, and libm3core (or else none of these) before recompiling & linking any code that reads or writes pickles. If libm3 and libm3core are dynamically linked in at runtime, you would have to recompile with an upgraded compiler at the same time as installing the upgraded dynamic libraries. Existing pickle files would not change. Also, mixtures of programs thus recompiled & linked and programs not recompiled/linked could exchange pickle files. Anything that (un)pickles records or objects that are LAZYALIGN would need the upgrade to work, but such programs are already broken. Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add support > for something that is rarely used. > Regards, > Randy > -- ------------------------------------------------------------- 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 -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 16:35:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:35:15 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> Message-ID: <47BEEBB3.6000800@wichita.edu> Darko wrote: > There wouldn't be any explicit expression. in the source, but there > would be a flag in Target.i3 for turning it off and on for different > platforms. > > Although the details may be a bit off, the principal is this: > > before byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 32 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) ^If the compiler's alignment rules are not lazy, then this violates a language rule and should not compile. From 2.2.5, Packed types: "...variables of type T that occur in records, objects, or arrays will occupy exactly n bits and be packed adjacent to the preceding field or element." To get the padding between a and b, you would have to either put it in with an explicit pad field, or remove the BITS 32 from the type of b. > c: BITS 16 FOR 0..65000; (* takes 32 bits *) > END; > > after byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 8 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 16 bits *) > END; > > > On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > >> Thanks for the explanation! How does one express the alignment you >> support? >> >> It does sound like <*LAZYALIGN*> can go away. >> >> On Feb 18, 2008, at 8:44 PM, Darko wrote: >> >>> Actually rather than compilain rather grumpily, maybe I can just >>> make the >>> changes required to RTTipe and do the work to reomve the pragma. I can >>> work with Randy to ensure it doesn't break pickles, there is no >>> reason why >>> it should. >>> >>> On tha subject Randy, I assume pickles encode the number of BITS FOR >>> for a field? If not it should. >>> >>> >>>> We seem to be going through these same point several times. I'm not >>>> sure >>>> what the difficulty is, I'm just repeating myself. >>>> >>>> Keep in mind this applies *only* to packed structures, ie BIT FOR >>>> or bit >>>> fields. >>>> >>>> The change I put in libralised the *M3* alignment rules so that >>>> BITS FOR >>>> fields in structures would align on byte boundries if possible >>>> instead of >>>> restricting them to word alignment generally. GCC happily generates >>>> code >>>> for this. There may be restrictions in GCC's C as to how you can >>>> arrange >>>> bit fields but I don't see what they have to do with M3. >>>> >>>> This is absolutely essentail for using the native APIs on Mac OS X >>>> and its >>>> removal would make M3 pointless for use on the Mac, at least more me. >>>> >>>> This should be the default behviour. If you are using BITS FOR it's >>>> becuase you want to arrange the fields in a record in particular >>>> way. Why >>>> then arbitrarliy pad out the fields? If performance is an issue, >>>> the user >>>> should be using appropriate field bit sizes. The implementation >>>> rule for >>>> BITS FOR in M3 is implementation dependent, there are no language >>>> issues. >>>> >>>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>>> created and had nothing to do with me. I diagreed with it and never >>>> used >>>> it in the version of the compiler I ran. I support its removal. >>>> >>>> >>>> >>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>> >>>>>> The alignment behaviour is absolutely crucial to programming >>>>>> natively in Mac OS X and should be kept. I have a great need for it. >>>>>> >>>>>> The PRGAMA is of no use and can be removed. >>>>>> >>>>>> Does anyone have any objections to making this alignment behaviour >>>>>> standard? >>>>> >>>>> >>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>>> the standard gcc-backend alignment? Perhaps I don't understand what >>>>> it is you are doing or trying to do. Again, please remind me what it >>>>> is that LAZYALIGN does and why it is needed. >>>>> >>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>> >>>>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>>> argue to abandon it. >>>>>>> >>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>> >>>>>>>> I use pickles extensively and they are used also by network >>>>>>>> objects. >>>>>>>> I've never used LAZYALIGN. >>>>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>>>> support for something that is rarely used. >>>>>>>> Regards, >>>>>>>> Randy >>>>>>>> >>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>> >>>>>>>> PM >>> >>>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>>>> requiring existing pickle files to be regenerated and/or existing >>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>> >>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>> pickles >>>>>>>> or compiled code were invalidated by a change? >>>>>>>> >>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>> variables of that type. >>>>>>>> >>>>>>>> Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>> >>>>>>>> LAZYALIGN. >>>>>>>> >>>>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>>>> >>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>> >>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>>> >>>>>>>> BITSIZE, >>>>>>>> >>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>> >>>>>>>> executing >>>>>>>> >>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>> >>>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>>> >>>>>>>> both as >>>>>>>> >>>>>>>>>> it is on the reading machine and as it was on the machine that >>>>>>>> >>>>>>>> wrote >>>>>>>> >>>>>>>>>> the pickle. The type description that the compiler generates is >>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>> >>>>>>>> field >>>>>>>> >>>>>>>>>> types (which are either recursive type descriptions or builtin >>>>>>>> >>>>>>>> types). >>>>>>>> >>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>> >>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>> >>>>>>>> machine >>>>>>>> >>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>> >>>>>>>> description and >>>>>>>> >>>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>>> >>>>>>>> as they >>>>>>>> >>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>> >>>>>>>> the latter, >>>>>>>> >>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>> >>>>>>>> stored in the >>>>>>>> >>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>> >>>>>>>> techniques >>>>>>>> >>>>>>>>>> like >>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>> >>>>>>>> m3core, and >>>>>>>> >>>>>>>>>> called by Pickle code. >>>>>>>>>> >>>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>>> >>>>>>>> layout >>>>>>>> >>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>> >>>>>>>> involve >>>>>>>> >>>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>>> >>>>>>>> data >>>>>>>> >>>>>>>>>> structure and code organization. It will be obvious what kind >>>>>>>> >>>>>>>> of bit >>>>>>>> >>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>> >>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>> >>>>>>>> comparing the >>>>>>>> >>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>> >>>>>>>> compiler. The >>>>>>>> >>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>> >>>>>>>>>> Note that all this is required even without any packing of >>>>>>>> >>>>>>>> small fields >>>>>>>> >>>>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>>>> >>>>>>>> on a >>>>>>>> >>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>> >>>>>>>>>> Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Rodney, >>>>>>>>>>> >>>>>>>>>>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>> >>>>>>>> anyway. >>>>>>>> >>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>> >>>>>>>> figure >>>>>>>> >>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>> >>>>>>>> INTEGER is >>>>>>>> >>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I missing >>>>>>>>>>> something? >>>>>>>>>>> >>>>>>>>>>> -- Tony >>>>>>>>>>> >>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>>> >>>>>>>> help with? >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>> >>>>>>>> recently) >>>>>>>> >>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>> >>>>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 16:40:44 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:40:44 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> References: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> Message-ID: <47BEECFC.8060308@wichita.edu> I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable for another, more serious reason, namely, that the byte ordering of type signatures in the files is different. I think this can be fixed by making pickle code try either byte ordering, without invalidating any existing pickle files. There would be a very remote chance of a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. Mika Nystrom wrote: > Ugh!!! I am still using compilers that are almost ten years old > on ALL my systems just because I need to share pickles between them > and CM3 has a different TEXT format from my ancient PM3. Tony > thinks there's a workaround with specials but I haven't had a chance > to get to it yet... > > > -- ------------------------------------------------------------- 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 darko at darko.org Fri Feb 22 16:33:47 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 02:33:47 +1100 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BEE918.1060908@wichita.edu> References: <47BEE918.1060908@wichita.edu> Message-ID: <1E474378-253C-4484-813B-A747EF28051B@darko.org> I don't think breaking pickles is at issue at all since the alignment issues don't change the meaning of a type, only its layout in memory on a particular platform, akin to endian issues. On 23/02/2008, at 2:24 AM, Rodney M. Bates wrote: > This didn't appear to come through to the list the first time: > > -------- Original Message -------- > Subject: Re: [M3devel] <*LAZYALIGN*> > Date: Mon, 18 Feb 2008 20:11:17 -0600 > From: Rodney M. Bates > To: Randy Coleburn > CC: m3devel at elegosoft.com > References: <47AF72B5.2080308 at wichita.edu> > <47B1168F.8020302 at wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236 at darko.org > > <47B4C70D.4010408 at wichita.edu> <7323567C-7632-4040-B858-47B8124759DC at cs.purdue.edu > > <47B50EDF.8060807 at wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843 at cs.purdue.edu > > <47B5FB13.7070407 at wichita.edu > > <20080215223205.t9a01icx4okgco0o at mail.elegosoft.com> <47B60CE0.8050506 at wichita.edu > > <47B9644F.1E75.00D7.1 at scires.com> > > Just to clarify: I don't believe anything existing has to break. The > worst scenario I can see is that you would have to either > simultaneously > upgrade the compiler, libm3, and libm3core (or else none of these) > before > recompiling & linking any code that reads or writes pickles. If > libm3 and > libm3core are dynamically linked in at runtime, you would have to > recompile > with an upgraded compiler at the same time as installing the upgraded > dynamic libraries. > > Existing pickle files would not change. Also, mixtures of programs > thus > recompiled & linked and programs not recompiled/linked could > exchange pickle > files. > > Anything that (un)pickles records or objects that are LAZYALIGN > would need > the upgrade to work, but such programs are already broken. > > Randy Coleburn wrote: >> I use pickles extensively and they are used also by network objects. >> I've never used LAZYALIGN. >> My vote is that we don't break something (pickles/netobj) to add >> support for something that is rarely used. >> Regards, >> Randy > -- > ------------------------------------------------------------- > 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 > > > -- > ------------------------------------------------------------- > 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 darko at darko.org Fri Feb 22 16:38:29 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 02:38:29 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BEEBB3.6000800@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> Message-ID: I think you may be reading that definition too literally. Any processor is going to data alignment rules so 'adjacent' is subject to what can be implemented on the processor. The problem I have is that the existing code doesn't pack to the limits of the processor, but to some arbitrary alignment. Thus my comment about viewing so-called lazy alignment as a fix to an alignment bug. On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > > > Darko wrote: >> There wouldn't be any explicit expression. in the source, but >> there would be a flag in Target.i3 for turning it off and on for >> different platforms. >> Although the details may be a bit off, the principal is this: >> before byte alignment change: >> RECORD >> a: BITS 8 FOR 0..255; (* takes 32 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) > > ^If the compiler's alignment rules are not lazy, then this violates > a language rule and should not compile. From 2.2.5, Packed types: > > "...variables of type T that occur in records, objects, or arrays will > occupy exactly n bits and be packed adjacent to the preceding field or > element." > > To get the padding between a and b, you would have to either put it in > with an explicit pad field, or remove the BITS 32 from the type of b. > >> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >> END; >> after byte alignment change: >> RECORD >> a: BITS 8 FOR 0..255; (* takes 8 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >> END; >> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >>> Thanks for the explanation! How does one express the alignment >>> you support? >>> >>> It does sound like <*LAZYALIGN*> can go away. >>> >>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>> >>>> Actually rather than compilain rather grumpily, maybe I can just >>>> make the >>>> changes required to RTTipe and do the work to reomve the pragma. >>>> I can >>>> work with Randy to ensure it doesn't break pickles, there is no >>>> reason why >>>> it should. >>>> >>>> On tha subject Randy, I assume pickles encode the number of BITS >>>> FOR >>>> for a field? If not it should. >>>> >>>> >>>>> We seem to be going through these same point several times. I'm >>>>> not sure >>>>> what the difficulty is, I'm just repeating myself. >>>>> >>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>> FOR or bit >>>>> fields. >>>>> >>>>> The change I put in libralised the *M3* alignment rules so that >>>>> BITS FOR >>>>> fields in structures would align on byte boundries if possible >>>>> instead of >>>>> restricting them to word alignment generally. GCC happily >>>>> generates code >>>>> for this. There may be restrictions in GCC's C as to how you >>>>> can arrange >>>>> bit fields but I don't see what they have to do with M3. >>>>> >>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>> X and its >>>>> removal would make M3 pointless for use on the Mac, at least >>>>> more me. >>>>> >>>>> This should be the default behviour. If you are using BITS FOR >>>>> it's >>>>> becuase you want to arrange the fields in a record in >>>>> particular way. Why >>>>> then arbitrarliy pad out the fields? If performance is an >>>>> issue, the user >>>>> should be using appropriate field bit sizes. The implementation >>>>> rule for >>>>> BITS FOR in M3 is implementation dependent, there are no >>>>> language issues. >>>>> >>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>> Olaf >>>>> created and had nothing to do with me. I diagreed with it and >>>>> never used >>>>> it in the version of the compiler I ran. I support its removal. >>>>> >>>>> >>>>> >>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>> >>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>> for it. >>>>>>> >>>>>>> The PRGAMA is of no use and can be removed. >>>>>>> >>>>>>> Does anyone have any objections to making this alignment >>>>>>> behaviour >>>>>>> standard? >>>>>> >>>>>> >>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>> with >>>>>> the standard gcc-backend alignment? Perhaps I don't >>>>>> understand what >>>>>> it is you are doing or trying to do. Again, please remind me >>>>>> what it >>>>>> is that LAZYALIGN does and why it is needed. >>>>>> >>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>> >>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>> with >>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>> would >>>>>>>> argue to abandon it. >>>>>>>> >>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>> >>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>> objects. >>>>>>>>> I've never used LAZYALIGN. >>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>> add >>>>>>>>> support for something that is rarely used. >>>>>>>>> Regards, >>>>>>>>> Randy >>>>>>>>> >>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>> >>>>>>>>> PM >>> >>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>> to >>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>> without >>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>> existing >>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>> >>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>> >>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>> variables of that type. >>>>>>>>> >>>>>>>>> Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>> the >>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>> >>>>>>>>> LAZYALIGN. >>>>>>>>> >>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>> pickles. >>>>>>>>>> >>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>> >>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>> Using >>>>>>>>> >>>>>>>>> BITSIZE, >>>>>>>>> >>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>> >>>>>>>>> executing >>>>>>>>> >>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>> >>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>> type >>>>>>>>> >>>>>>>>> both as >>>>>>>>> >>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>> that >>>>>>>>> >>>>>>>>> wrote >>>>>>>>> >>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>> generates is >>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>> >>>>>>>>> field >>>>>>>>> >>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>> builtin >>>>>>>>> >>>>>>>>> types). >>>>>>>>> >>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>> >>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>> >>>>>>>>> machine >>>>>>>>> >>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>> >>>>>>>>> description and >>>>>>>>> >>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>> both >>>>>>>>> >>>>>>>>> as they >>>>>>>>> >>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>> >>>>>>>>> the latter, >>>>>>>>> >>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>> >>>>>>>>> stored in the >>>>>>>>> >>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>> >>>>>>>>> techniques >>>>>>>>> >>>>>>>>>>> like >>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>> >>>>>>>>> m3core, and >>>>>>>>> >>>>>>>>>>> called by Pickle code. >>>>>>>>>>> >>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>> compiler's >>>>>>>>> >>>>>>>>> layout >>>>>>>>> >>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>> >>>>>>>>> involve >>>>>>>>> >>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>> different >>>>>>>>> >>>>>>>>> data >>>>>>>>> >>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>> kind >>>>>>>>> >>>>>>>>> of bit >>>>>>>>> >>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>> >>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>> >>>>>>>>> comparing the >>>>>>>>> >>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>> >>>>>>>>> compiler. The >>>>>>>>> >>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>> >>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>> >>>>>>>>> small fields >>>>>>>>> >>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>> pickled >>>>>>>>> >>>>>>>>> on a >>>>>>>>> >>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Rodney, >>>>>>>>>>>> >>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>> RTPacking? I >>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>> >>>>>>>>> anyway. >>>>>>>>> >>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>> >>>>>>>>> figure >>>>>>>>> >>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>> >>>>>>>>> INTEGER is >>>>>>>>> >>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>> missing >>>>>>>>>>>> something? >>>>>>>>>>>> >>>>>>>>>>>> -- Tony >>>>>>>>>>>> >>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>> can >>>>>>>>> >>>>>>>>> help with? >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>> type >>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>> >>>>>>>>> recently) >>>>>>>>> >>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Fri Feb 22 22:19:15 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 22 Feb 2008 13:19:15 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> Message-ID: <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> Oh I should be clear on what I mean, exactly, when I say things like that. Pickles "version 1", what was in SRC M3 and is in PM3, were never from what I understand completely implemented? For one thing, they didn't support endian-switching. A gentleman with a Scottish name that eludes me at the moment came out with "Pickles version 2", which do the endianness-switching, among other things. My "PM3" includes a lot of things from newer M3s, such as this Pickles version 2. I really am not enamored with my ancient PM3. I just need something that works reliably on Cygwin *and* FreeBSD (which it does). So adding the odd CM3 library to it is no big deal. But the TEXT issue is so deeply embedded in the compiler and runtime that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or vice versa. I am almost certain I have tested interchanging pickles between my PM3 code and some CM3 code and verified that it did work as long as there were no TEXTs involved. (It was a couple of years ago I did this; I think I spammed m3devel about it then too.) Mika "Rodney M. Bates" writes: >I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable >for another, more serious reason, namely, that the byte ordering of type >signatures in the files is different. > >I think this can be fixed by making pickle code try either byte ordering, without >invalidating any existing pickle files. There would be a very remote chance of >a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. > >Mika Nystrom wrote: >> Ugh!!! I am still using compilers that are almost ten years old >> on ALL my systems just because I need to share pickles between them >> and CM3 has a different TEXT format from my ancient PM3. Tony >> thinks there's a workaround with specials but I haven't had a chance >> to get to it yet... >> >> >> >-- >------------------------------------------------------------- >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 mika at async.caltech.edu Fri Feb 22 22:20:52 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 22 Feb 2008 13:20:52 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Sat, 23 Feb 2008 02:38:29 +1100." Message-ID: <200802222120.m1MLKqbK010997@camembert.async.caltech.edu> Hmm, can't you always write code to force whatever bit pattern you like, if you absolutely insist on it? One could read the specification that way too. Mika Darko writes: >I think you may be reading that definition too literally. Any >processor is going to data alignment rules so 'adjacent' is subject to >what can be implemented on the processor. The problem I have is that >the existing code doesn't pack to the limits of the processor, but to >some arbitrary alignment. Thus my comment about viewing so-called lazy >alignment as a fix to an alignment bug. > > >On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > >> >> >> Darko wrote: >>> There wouldn't be any explicit expression. in the source, but >>> there would be a flag in Target.i3 for turning it off and on for >>> different platforms. >>> Although the details may be a bit off, the principal is this: >>> before byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> >> ^If the compiler's alignment rules are not lazy, then this violates >> a language rule and should not compile. From 2.2.5, Packed types: >> >> "...variables of type T that occur in records, objects, or arrays will >> occupy exactly n bits and be packed adjacent to the preceding field or >> element." >> >> To get the padding between a and b, you would have to either put it in >> with an explicit pad field, or remove the BITS 32 from the type of b. >> >>> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >>> END; >>> after byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 8 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >>> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >>> END; >>> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >>>> Thanks for the explanation! How does one express the alignment >>>> you support? >>>> >>>> It does sound like <*LAZYALIGN*> can go away. >>>> >>>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>>> >>>>> Actually rather than compilain rather grumpily, maybe I can just >>>>> make the >>>>> changes required to RTTipe and do the work to reomve the pragma. >>>>> I can >>>>> work with Randy to ensure it doesn't break pickles, there is no >>>>> reason why >>>>> it should. >>>>> >>>>> On tha subject Randy, I assume pickles encode the number of BITS >>>>> FOR >>>>> for a field? If not it should. >>>>> >>>>> >>>>>> We seem to be going through these same point several times. I'm >>>>>> not sure >>>>>> what the difficulty is, I'm just repeating myself. >>>>>> >>>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>>> FOR or bit >>>>>> fields. >>>>>> >>>>>> The change I put in libralised the *M3* alignment rules so that >>>>>> BITS FOR >>>>>> fields in structures would align on byte boundries if possible >>>>>> instead of >>>>>> restricting them to word alignment generally. GCC happily >>>>>> generates code >>>>>> for this. There may be restrictions in GCC's C as to how you >>>>>> can arrange >>>>>> bit fields but I don't see what they have to do with M3. >>>>>> >>>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>>> X and its >>>>>> removal would make M3 pointless for use on the Mac, at least >>>>>> more me. >>>>>> >>>>>> This should be the default behviour. If you are using BITS FOR >>>>>> it's >>>>>> becuase you want to arrange the fields in a record in >>>>>> particular way. Why >>>>>> then arbitrarliy pad out the fields? If performance is an >>>>>> issue, the user >>>>>> should be using appropriate field bit sizes. The implementation >>>>>> rule for >>>>>> BITS FOR in M3 is implementation dependent, there are no >>>>>> language issues. >>>>>> >>>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>>> Olaf >>>>>> created and had nothing to do with me. I diagreed with it and >>>>>> never used >>>>>> it in the version of the compiler I ran. I support its removal. >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>>> >>>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>>> for it. >>>>>>>> >>>>>>>> The PRGAMA is of no use and can be removed. >>>>>>>> >>>>>>>> Does anyone have any objections to making this alignment >>>>>>>> behaviour >>>>>>>> standard? >>>>>>> >>>>>>> >>>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>>> with >>>>>>> the standard gcc-backend alignment? Perhaps I don't >>>>>>> understand what >>>>>>> it is you are doing or trying to do. Again, please remind me >>>>>>> what it >>>>>>> is that LAZYALIGN does and why it is needed. >>>>>>> >>>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>>> >>>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>>> with >>>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>>> would >>>>>>>>> argue to abandon it. >>>>>>>>> >>>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>>> >>>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>>> objects. >>>>>>>>>> I've never used LAZYALIGN. >>>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>>> add >>>>>>>>>> support for something that is rarely used. >>>>>>>>>> Regards, >>>>>>>>>> Randy >>>>>>>>>> >>>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>>> >>>>>>>>>> PM >>> >>>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>>> to >>>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>>> without >>>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>>> existing >>>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>>> >>>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>>> >>>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>>> variables of that type. >>>>>>>>>> >>>>>>>>>> Olaf Wagner wrote: >>>>>>>>>> >>>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>>> the >>>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>>> >>>>>>>>>>> Olaf >>>>>>>>>>> >>>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>>> >>>>>>>>>> LAZYALIGN. >>>>>>>>>> >>>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>>> pickles. >>>>>>>>>>> >>>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>>> >>>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>>> Using >>>>>>>>>> >>>>>>>>>> BITSIZE, >>>>>>>>>> >>>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>>> >>>>>>>>>> executing >>>>>>>>>> >>>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>>> >>>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>>> type >>>>>>>>>> >>>>>>>>>> both as >>>>>>>>>> >>>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>>> that >>>>>>>>>> >>>>>>>>>> wrote >>>>>>>>>> >>>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>>> generates is >>>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>>> >>>>>>>>>> field >>>>>>>>>> >>>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>>> builtin >>>>>>>>>> >>>>>>>>>> types). >>>>>>>>>> >>>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>>> >>>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>>> >>>>>>>>>> machine >>>>>>>>>> >>>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>>> >>>>>>>>>> description and >>>>>>>>>> >>>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>>> both >>>>>>>>>> >>>>>>>>>> as they >>>>>>>>>> >>>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>>> >>>>>>>>>> the latter, >>>>>>>>>> >>>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>>> >>>>>>>>>> stored in the >>>>>>>>>> >>>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>>> >>>>>>>>>> techniques >>>>>>>>>> >>>>>>>>>>>> like >>>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>>> >>>>>>>>>> m3core, and >>>>>>>>>> >>>>>>>>>>>> called by Pickle code. >>>>>>>>>>>> >>>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>>> compiler's >>>>>>>>>> >>>>>>>>>> layout >>>>>>>>>> >>>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>>> >>>>>>>>>> involve >>>>>>>>>> >>>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>>> different >>>>>>>>>> >>>>>>>>>> data >>>>>>>>>> >>>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>>> kind >>>>>>>>>> >>>>>>>>>> of bit >>>>>>>>>> >>>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>>> >>>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>>> >>>>>>>>>> comparing the >>>>>>>>>> >>>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>>> >>>>>>>>>> compiler. The >>>>>>>>>> >>>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>>> >>>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>>> >>>>>>>>>> small fields >>>>>>>>>> >>>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>>> pickled >>>>>>>>>> >>>>>>>>>> on a >>>>>>>>>> >>>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>>> >>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Rodney, >>>>>>>>>>>>> >>>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>>> RTPacking? I >>>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>>> >>>>>>>>>> anyway. >>>>>>>>>> >>>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>>> >>>>>>>>>> figure >>>>>>>>>> >>>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>>> >>>>>>>>>> INTEGER is >>>>>>>>>> >>>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>>> missing >>>>>>>>>>>>> something? >>>>>>>>>>>>> >>>>>>>>>>>>> -- Tony >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>>> can >>>>>>>>>> >>>>>>>>>> help with? >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>>> type >>>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>>> >>>>>>>>>> recently) >>>>>>>>>> >>>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >> >> -- >> ------------------------------------------------------------- >> 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 rodney.bates at wichita.edu Fri Feb 22 22:49:33 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 15:49:33 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> Message-ID: <47BF436D.9080608@wichita.edu> No, this is exactly what the language says and means. However, there is more, in the same section that I took for granted: "The values allowed for n are implementation-dependent. An illegal value for n is a static error. The legality of a packed type can depend on its context; for example, an implementation could prohibit packed integers from spanning word boundaries." In other words, the compiler must either locate a packed field with no preceding padding, or else emit an error, and this is what both PM3 and CM3 do. LAZYALIGN weakens the CM3's restrictions and changes the handling of your example from a a compile error to respecting the no-padding rule. Either way is consistent with the language. Darko wrote: > I think you may be reading that definition too literally. Any processor > is going to data alignment rules so 'adjacent' is subject to what can > be implemented on the processor. The problem I have is that the > existing code doesn't pack to the limits of the processor, but to some > arbitrary alignment. Thus my comment about viewing so-called lazy > alignment as a fix to an alignment bug. > > > On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > >> >> >> Darko wrote: >> >>> There wouldn't be any explicit expression. in the source, but there >>> would be a flag in Target.i3 for turning it off and on for >>> different platforms. >>> Although the details may be a bit off, the principal is this: >>> before byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> >> >> ^If the compiler's alignment rules are not lazy, then this violates >> a language rule and should not compile. From 2.2.5, Packed types: >> >> "...variables of type T that occur in records, objects, or arrays will >> occupy exactly n bits and be packed adjacent to the preceding field or >> element." >> >> To get the padding between a and b, you would have to either put it in >> with an explicit pad field, or remove the BITS 32 from the type of b. >> -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 23:01:16 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 16:01:16 -0600 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <1E474378-253C-4484-813B-A747EF28051B@darko.org> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> Message-ID: <47BF462C.6060204@wichita.edu> But pickles are working below the type safety of the language, copying bits around. True, pickles will only build an object in the reading program with the same type it had in the writing program. But the layout of fields can be different, even with the same type, for example, due to integer size, or as you say, endianness. Pickles has to be able to reconstruct the bit layout of a type both as it was on the writing machine and as it is on the reading machine. If anything LAZYALIGN is written to a pickle, then it's already broken, because pickles will have the wrong idea about where the bits of the fields are located and will garble bits. Pickles always recomputes bit layouts as the compiler would for STRICTALIGN. Which means, if you never pickle anything that is LAZYALIGN, you won't invoke this brokenness. And it sounds like nobody is doing that, so it's not broken for current uses. Darko wrote: > I don't think breaking pickles is at issue at all since the alignment > issues don't change the meaning of a type, only its layout in memory on > a particular platform, akin to endian issues. > >-- ------------------------------------------------------------- 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 rcoleburn at scires.com Sat Feb 23 01:16:36 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 22 Feb 2008 19:16:36 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> References: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> Message-ID: <47BF1F8F.1E75.00D7.1@scires.com> Mika: I believe the person you are referencing is Blair McIntyre. Last time I communicated with him he was a professor at Georgia Tech. Regards, Randy >>> Mika Nystrom 2/22/2008 4:19 PM >>> Oh I should be clear on what I mean, exactly, when I say things like that. Pickles "version 1", what was in SRC M3 and is in PM3, were never from what I understand completely implemented? For one thing, they didn't support endian-switching. A gentleman with a Scottish name that eludes me at the moment came out with "Pickles version 2", which do the endianness-switching, among other things. My "PM3" includes a lot of things from newer M3s, such as this Pickles version 2. I really am not enamored with my ancient PM3. I just need something that works reliably on Cygwin *and* FreeBSD (which it does). So adding the odd CM3 library to it is no big deal. But the TEXT issue is so deeply embedded in the compiler and runtime that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or vice versa. I am almost certain I have tested interchanging pickles between my PM3 code and some CM3 code and verified that it did work as long as there were no TEXTs involved. (It was a couple of years ago I did this; I think I spammed m3devel about it then too.) Mika "Rodney M. Bates" writes: >I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable >for another, more serious reason, namely, that the byte ordering of type >signatures in the files is different. > >I think this can be fixed by making pickle code try either byte ordering, without >invalidating any existing pickle files. There would be a very remote chance of >a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. > >Mika Nystrom wrote: >> Ugh!!! I am still using compilers that are almost ten years old >> on ALL my systems just because I need to share pickles between them >> and CM3 has a different TEXT format from my ancient PM3. Tony >> thinks there's a workaround with specials but I haven't had a chance >> to get to it yet... >> >> >> >-- >------------------------------------------------------------- >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 rcoleburn at scires.com Sat Feb 23 01:21:05 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 22 Feb 2008 19:21:05 -0500 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BF462C.6060204@wichita.edu> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> Message-ID: <47BF209D.1E75.00D7.1@scires.com> I agree with Rodney. Regards, Randy >>> "Rodney M. Bates" 2/22/2008 5:01 PM >>> But pickles are working below the type safety of the language, copying bits around. True, pickles will only build an object in the reading program with the same type it had in the writing program. But the layout of fields can be different, even with the same type, for example, due to integer size, or as you say, endianness. Pickles has to be able to reconstruct the bit layout of a type both as it was on the writing machine and as it is on the reading machine. If anything LAZYALIGN is written to a pickle, then it's already broken, because pickles will have the wrong idea about where the bits of the fields are located and will garble bits. Pickles always recomputes bit layouts as the compiler would for STRICTALIGN. Which means, if you never pickle anything that is LAZYALIGN, you won't invoke this brokenness. And it sounds like nobody is doing that, so it's not broken for current uses. Darko wrote: > I don't think breaking pickles is at issue at all since the alignment > issues don't change the meaning of a type, only its layout in memory on > a particular platform, akin to endian issues. > >-- ------------------------------------------------------------- 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 darko at darko.org Sat Feb 23 02:01:55 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 12:01:55 +1100 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BF462C.6060204@wichita.edu> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> Message-ID: <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> Then I assume RTTipe needs to be fixed, and pickles and the alignment are ok. On 23/02/2008, at 9:01 AM, Rodney M. Bates wrote: > But pickles are working below the type safety of the language, copying > bits around. True, pickles will only build an object in the reading > program with the same type it had in the writing program. But the > layout of fields can be different, even with the same type, for > example, > due to integer size, or as you say, endianness. Pickles has to be > able > to reconstruct the bit layout of a type both as it was on the writing > machine and as it is on the reading machine. > > If anything LAZYALIGN is written to a pickle, then it's already > broken, > because pickles will have the wrong idea about where the bits of the > fields are located and will garble bits. Pickles always recomputes > bit layouts as the compiler would for STRICTALIGN. > > Which means, if you never pickle anything that is LAZYALIGN, you won't > invoke this brokenness. And it sounds like nobody is doing that, so > it's not broken for current uses. > > Darko wrote: >> I don't think breaking pickles is at issue at all since the >> alignment issues don't change the meaning of a type, only its >> layout in memory on a particular platform, akin to endian issues. >> -- > ------------------------------------------------------------- > 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 darko at darko.org Sat Feb 23 02:07:16 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 12:07:16 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF436D.9080608@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> Message-ID: <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> It's been several years since I looked at the code, so my recollection is obviously faulty. But this means that the actual change is a positive one, allowing more packings to be legal, and there is no need for any pragmas. So the new alignment rules would be that for any platform that allows it, allow fields to align on byte boundaries, except traced references that must be aligned on word boundaries. This would mean that a pickle packed on a platform with the more liberal alignment might be illegal on another platform. Therefore caution should be taken, otherwise I see no problem with this. On 23/02/2008, at 8:49 AM, Rodney M. Bates wrote: > No, this is exactly what the language says and means. However, > there is > more, in the same section that I took for granted: > > "The values allowed for n are implementation-dependent. An illegal > value for n is a > static error. The legality of a packed type can depend on its > context; for example, an > implementation could prohibit packed integers from spanning word > boundaries." > > In other words, the compiler must either locate a packed field with > no preceding > padding, or else emit an error, and this is what both PM3 and CM3 > do. LAZYALIGN > weakens the CM3's restrictions and changes the handling of your > example from a > a compile error to respecting the no-padding rule. Either way is > consistent with > the language. > > Darko wrote: >> I think you may be reading that definition too literally. Any >> processor is going to data alignment rules so 'adjacent' is subject >> to what can be implemented on the processor. The problem I have is >> that the existing code doesn't pack to the limits of the >> processor, but to some arbitrary alignment. Thus my comment about >> viewing so-called lazy alignment as a fix to an alignment bug. >> On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: >>> >>> >>> Darko wrote: >>> >>>> There wouldn't be any explicit expression. in the source, but >>>> there would be a flag in Target.i3 for turning it off and on >>>> for different platforms. >>>> Although the details may be a bit off, the principal is this: >>>> before byte alignment change: >>>> RECORD >>>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >>> >>> >>> ^If the compiler's alignment rules are not lazy, then this violates >>> a language rule and should not compile. From 2.2.5, Packed types: >>> >>> "...variables of type T that occur in records, objects, or arrays >>> will >>> occupy exactly n bits and be packed adjacent to the preceding >>> field or >>> element." >>> >>> To get the padding between a and b, you would have to either put >>> it in >>> with an explicit pad field, or remove the BITS 32 from the type of >>> b. >>> > > -- > ------------------------------------------------------------- > 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 rodney.bates at wichita.edu Sat Feb 23 05:07:38 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 22:07:38 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> Message-ID: <47BF9C0A.8000804@wichita.edu> Darko wrote: > It's been several years since I looked at the code, so my recollection > is obviously faulty. But this means that the actual change is a > positive one, allowing more packings to be legal, and there is no need > for any pragmas. > > So the new alignment rules would be that for any platform that allows > it, allow fields to align on byte boundaries, except traced references > that must be aligned on word boundaries. > > This would mean that a pickle packed on a platform with the more > liberal alignment might be illegal on another platform. Therefore > caution should be taken, otherwise I see no problem with this. > > Actually, if RTTipe can detect this illegality, then it can just as easily make it legal and accommodate it, rearranging the fields to the new displacements. It already does this for other reasons anyway. The tricky design problem is how to communicate to RTTipe code, which rules were used. If a mix of different rules exists anywhere in the universe, either in different compilers or in the same compiler with different options, then it must be somehow encoded in a type description, as read by RTTipe, which rules were used. Otherwise, RTTipe not even detect this mismatch, and bits get shuffled. And do this without invalidating existing pickle files and existing compiled code (where the type descriptions are stored.) -- ------------------------------------------------------------- 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 darko at darko.org Sat Feb 23 06:33:13 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 16:33:13 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF9C0A.8000804@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> Message-ID: The alignment rules are particular to a platform, not a type (at least after we get rid of the pragma), so is there no field where we can encode some information about the platform in the pickle header or something? Where is endian stored? On 23/02/2008, at 3:07 PM, Rodney M. Bates wrote: > > > Darko wrote: >> It's been several years since I looked at the code, so my >> recollection is obviously faulty. But this means that the actual >> change is a positive one, allowing more packings to be legal, and >> there is no need for any pragmas. >> So the new alignment rules would be that for any platform that >> allows it, allow fields to align on byte boundaries, except traced >> references that must be aligned on word boundaries. >> This would mean that a pickle packed on a platform with the more >> liberal alignment might be illegal on another platform. Therefore >> caution should be taken, otherwise I see no problem with this. >> > Actually, if RTTipe can detect this illegality, then it can just > as easily make it legal and accommodate it, rearranging the fields > to the new displacements. It already does this for other reasons > anyway. > > The tricky design problem is how to communicate to RTTipe code, which > rules were used. If a mix of different rules exists anywhere in the > universe, either in different compilers or in the same compiler with > different options, then it must be somehow encoded in a type > description, > as read by RTTipe, which rules were used. Otherwise, RTTipe not > even detect > this mismatch, and bits get shuffled. And do this without > invalidating > existing pickle files and existing compiled code (where the type > descriptions are stored.) > -- > ------------------------------------------------------------- > 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 Sat Feb 23 11:14:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 10:14:49 +0000 Subject: [M3devel] response file changes? In-Reply-To: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: "response files" are files that contain command lines, to overcomecommand line length limits. (Why the limits are so small? Lame.) CM3 has built in support for them. I have seen them not be deleted reliably. While the deletion should be made more reliable, I propose they be writteninto the target directory instead of "temp". That is, nearly all writes should be into the target directory.This is what is reliably cleaned up when you run "realclean". I realize there is a tension between putting things that belong together together, and reliable deletion, vs. load balancing of I/O. "Temp" is sometimes smaller/faster. I had already worked around this by wrapping up the response file supportin Quake code that moves the file into the target directory immediatelyafter creating it. I'll be able to remove that code, and live with theunreliably deleted files only when using older tools. ? Also, the built in support uses a heuristic.For shorter command lines, it doesn't use a response file.I found that surprising and a bit disappointing.While a more immediately readable log is valuable, consistency is too. Leave it alone or make it always use a response file? The Microsoft C compiler and linker dump the output of any response filethey are given, so that gets you a readable log. I don't care all that much. Maybe I'll just look into why the deletion is unreliable, but I figure "cleanup" is always unreliable because you might control-c the build, or the compiler might crash, etc. There is a "delete on close" flag in Windows, but I think it has a problem in that you have to keep the file open and if anyone else also opens it, they might need file_share_delete, not sure. File_share_delete not being supported on Win9x, maybe not much used? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 12:04:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 12:04:46 +0100 Subject: [M3devel] response file changes? In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Two short comments: o Response files in the target directory should be OK, as long as their names are unique. o The heuristic is built-in to arglist(pfx, array), IIRC; I wouldn't change that without need. You never know what depends on it, as it has been there for a long time. Olaf Quoting Jay : > "response files" are files that contain command lines, to > overcomecommand line length limits. (Why the limits are so small? > Lame.) > CM3 has built in support for them. > I have seen them not be deleted reliably. > While the deletion should be made more reliable, I propose they be > writteninto the target directory instead of "temp". > That is, nearly all writes should be into the target directory.This > is what is reliably cleaned up when you run "realclean". > > I realize there is a tension between putting things that belong > together together, and reliable deletion, vs. load balancing of I/O. > "Temp" is sometimes smaller/faster. > I had already worked around this by wrapping up the response file > supportin Quake code that moves the file into the target directory > immediatelyafter creating it. I'll be able to remove that code, and > live with theunreliably deleted files only when using older tools. > ? > Also, the built in support uses a heuristic.For shorter command > lines, it doesn't use a response file.I found that surprising and a > bit disappointing.While a more immediately readable log is valuable, > consistency is too. > Leave it alone or make it always use a response file? > The Microsoft C compiler and linker dump the output of any response > filethey are given, so that gets you a readable log. > > I don't care all that much. > Maybe I'll just look into why the deletion is unreliable, but I > figure "cleanup" is always unreliable because you might control-c > the build, or the compiler might crash, etc. There is a "delete on > close" flag in Windows, but I think it has a problem in that you > have to keep the file open and if anyone else also opens it, they > might need file_share_delete, not sure. File_share_delete not being > supported on Win9x, maybe not much used? > > - Jay > _________________________________________________________________ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". > http://www.msnmobilefix.com/Default.aspx -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 12:59:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 11:59:46 +0000 Subject: [M3devel] paths.. In-Reply-To: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: I could be wrong about many things here: Cygwin fopen and I presume open accepts all of: c:\foo, c:/foo, /foo, \foo /foo and \foo probably have a different meaning between Cygwin and Win32. In Win32, /foo and \foo are, well, \foo, on the current drive. In Cygwin, /foo is probably /foo at the Cygwin root. I'd kind of like to be wrong here, about \foo having different meanings between them, since it a common form for me. Cygwin does not accept c:foo. In Win32 c:foo is foo in the current working directory of the C: drive. I don't think c:foo is used often, but it does have a meaning. Now, as well, cm3 has its own Path module, M3Path, but I realized tonight it also uses libm3's Pathname module a fair amount. In particular, I was having errors "shipping". This throws a big monkey wrench into where I was going. So now, after a bunch of going back and forth on various uncommited changes, I have now switched (and commited) NT386GNU to use PathnameWin32.m3. To some extent, this strikes at the core of "what is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". However, remember that Cygwin does appear to accept Win32 paths. So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that Win32 accepts /foo, is it Posix?) As well, this target still uses cygwin1.dll for its all its odd behaviors. It still uses open/read/write (again, remember that msvcrt.dll DOES expose these SAME functions..I still contend that Win32 is close enough to Posix to satisfy almost everyone..and then X Windows can be dealt with separately maybe, or Trestle/Win32 fixed). I have some more testing to do but I think this switch will fly, and various other options can go away. And I can undo the small amount I had commited. I think I'll just send my m3path.m3 diff around and then delete it. I ended up with a set based approach where host and target have a set of dir separaters, volume separaters, and separators (union of previous two). These are TINY sets, containing a maximum of three characters each, and '/' is always a member of two of them. So a set is kind of overkill. But it works out pretty ok. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 13:03:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 12:03:50 +0000 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: attached contains diffs and resulting files - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 23 Feb 2008 11:59:46 +0000Subject: [M3devel] paths.. I could be wrong about many things here: Cygwin fopen and I presume open accepts all of: c:\foo, c:/foo, /foo, \foo /foo and \foo probably have a different meaning between Cygwin and Win32.In Win32, /foo and \foo are, well, \foo, on the current drive.In Cygwin, /foo is probably /foo at the Cygwin root.I'd kind of like to be wrong here, about \foo having different meanings between them, since it a common form for me. Cygwin does not accept c:foo.In Win32 c:foo is foo in the current working directory of the C: drive.I don't think c:foo is used often, but it does have a meaning. Now, as well, cm3 has its own Path module, M3Path, but I realized tonight it also uses libm3's Pathname module a fair amount. In particular, I was having errors "shipping". This throws a big monkey wrench into where I was going.So now, after a bunch of going back and forth on various uncommited changes, I have now switched (and commited) NT386GNU to use PathnameWin32.m3. To some extent, this strikes at the core of "what is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". However, remember that Cygwin does appear to accept Win32 paths. So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that Win32 accepts /foo, is it Posix?) As well, this target still uses cygwin1.dll for its all its odd behaviors. It still uses open/read/write (again, remember that msvcrt.dll DOES expose these SAME functions..I still contend that Win32 is close enough to Posix to satisfy almost everyone..and then X Windows can be dealt with separately maybe, or Trestle/Win32 fixed). I have some more testing to do but I think this switch will fly, and various other options can go away.And I can undo the small amount I had commited.I think I'll just send my m3path.m3 diff around and then delete it. I ended up with a set based approach where host and target have a set of dir separaters, volume separaters, and separators (union of previous two). These are TINY sets, containing a maximum of three characters each, and '/' is always a member of two of them. So a set is kind of overkill. But it works out pretty ok. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: path.tar.gz Type: application/x-gzip Size: 49603 bytes Desc: not available URL: From wagner at elegosoft.com Sat Feb 23 13:39:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 13:39:09 +0100 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Jay, I'm not really happy with NT386GNU using PathnameWin32.m3. In my opininion it should just use the POSIX code, whatever problems people will have with their installation roots. (These can be avoided by using the /cygdrive/... equivalents.) Why don't we just assume that by deafult CM3 is installed in /usr/local/cm3 as for all other targets (except NT386, of course)? One thing that immediately comes to mind is that all paths output by CM3 programs will contain \ instead of / then and thus be unusable for simple copy-and-paste, as \ is the escape character in all POSIX command line tools. So this seems kind of incompatible to me. Olaf Quoting Jay : > I could be wrong about many things here: > > Cygwin fopen and I presume open accepts all of: > c:\foo, c:/foo, /foo, \foo > > /foo and \foo probably have a different meaning between Cygwin and Win32. > In Win32, /foo and \foo are, well, \foo, on the current drive. > In Cygwin, /foo is probably /foo at the Cygwin root. > I'd kind of like to be wrong here, about \foo having different > meanings between them, since it a common form for me. > > Cygwin does not accept c:foo. > In Win32 c:foo is foo in the current working directory of the C: drive. > I don't think c:foo is used often, but it does have a meaning. > > Now, as well, cm3 has its own Path module, M3Path, but I realized > tonight it also uses libm3's Pathname module a fair amount. In > particular, I was having errors "shipping". > > This throws a big monkey wrench into where I was going. > So now, after a bunch of going back and forth on various uncommited > changes, I have now switched (and commited) NT386GNU to use > PathnameWin32.m3. To some extent, this strikes at the core of "what > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > However, remember that Cygwin does appear to accept Win32 paths. > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > Win32 accepts /foo, is it Posix?) As well, this target still uses > cygwin1.dll for its all its odd behaviors. It still uses > open/read/write (again, remember that msvcrt.dll DOES expose these > SAME functions..I still contend that Win32 is close enough to Posix > to satisfy almost everyone..and then X Windows can be dealt with > separately maybe, or Trestle/Win32 fixed). > > I have some more testing to do but I think this switch will fly, and > various other options can go away. > And I can undo the small amount I had commited. > I think I'll just send my m3path.m3 diff around and then delete it. > > I ended up with a set based approach where host and target have a > set of dir separaters, volume separaters, and separators (union of > previous two). These are TINY sets, containing a maximum of three > characters each, and '/' is always a member of two of them. So a set > is kind of overkill. But it works out pretty ok. > > - Jay > _________________________________________________________________ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". > http://www.msnmobilefix.com/Default.aspx -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 14:07:09 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:07:09 +0000 Subject: [M3devel] paths.. In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: They'll be escaped.?Olaf, I'm just not sure. It could be that if I just set CM3_ROOT, CM3_INSTALL, and possibly M3_CONFIG, then the Posix code is ok. However, note as I said that Cygwin does accept these paths..The opposite problem holds too -- I like copy/pasting the error messages into file.open dialogs, and forward slashes don't work there unfortunately. I had a diff for a bit that between \ and /, would try to use whatever was already in the data. I had a problem with but it still might be viable, specifically in the Win32 paths. Maybe if I can just get it definitely usable (maybe already there) and get a distribution out, someone else can hack on this issue.. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Jay,> > I'm not really happy with NT386GNU using PathnameWin32.m3.> In my opininion it should just use the POSIX code, whatever problems> people will have with their installation roots. (These can be avoided> by using the /cygdrive/... equivalents.)> Why don't we just assume that by deafult CM3 is installed in> /usr/local/cm3 as for all other targets (except NT386, of course)?> > One thing that immediately comes to mind is that all paths output> by CM3 programs will contain \ instead of / then and thus be> unusable for simple copy-and-paste, as \ is the escape character> in all POSIX command line tools. So this seems kind of incompatible> to me.> > Olaf> > Quoting Jay :> > > I could be wrong about many things here:> >> > Cygwin fopen and I presume open accepts all of:> > c:\foo, c:/foo, /foo, \foo> >> > /foo and \foo probably have a different meaning between Cygwin and Win32.> > In Win32, /foo and \foo are, well, \foo, on the current drive.> > In Cygwin, /foo is probably /foo at the Cygwin root.> > I'd kind of like to be wrong here, about \foo having different > > meanings between them, since it a common form for me.> >> > Cygwin does not accept c:foo.> > In Win32 c:foo is foo in the current working directory of the C: drive.> > I don't think c:foo is used often, but it does have a meaning.> >> > Now, as well, cm3 has its own Path module, M3Path, but I realized > > tonight it also uses libm3's Pathname module a fair amount. In > > particular, I was having errors "shipping".> >> > This throws a big monkey wrench into where I was going.> > So now, after a bunch of going back and forth on various uncommited > > changes, I have now switched (and commited) NT386GNU to use > > PathnameWin32.m3. To some extent, this strikes at the core of "what > > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > > However, remember that Cygwin does appear to accept Win32 paths. > > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > > Win32 accepts /foo, is it Posix?) As well, this target still uses > > cygwin1.dll for its all its odd behaviors. It still uses > > open/read/write (again, remember that msvcrt.dll DOES expose these > > SAME functions..I still contend that Win32 is close enough to Posix > > to satisfy almost everyone..and then X Windows can be dealt with > > separately maybe, or Trestle/Win32 fixed).> >> > I have some more testing to do but I think this switch will fly, and > > various other options can go away.> > And I can undo the small amount I had commited.> > I think I'll just send my m3path.m3 diff around and then delete it.> >> > I ended up with a set based approach where host and target have a > > set of dir separaters, volume separaters, and separators (union of > > previous two). These are TINY sets, containing a maximum of three > > characters each, and '/' is always a member of two of them. So a set > > is kind of overkill. But it works out pretty ok.> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 14:30:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:30:28 +0000 Subject: [M3devel] bringing up NT386GNU a bit easier now In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: It is now a bit easier to bring up NT386GNU. (because of the path change mainly) Remember to remove spaces from start/ends of lines in my mail (they inhibit misformatting..email systems really stink these days..). Again, cm3cg.exe I had already, and sitting in an otherwise 5.1.8 tree so I set OMIT_GCC=yes rmdir /q/s \cm3 xcopy /fivery \cm3-min-WIN32-NT386-5.1.8 \cm3 Newer versions should of course work fine. c:\cm3\bin is in %PATH%: set PATH=c:\cygwin\bin;%PATH% Cygwin is in the %PATH%: set PATH=c:\cygwin\bin;%PATH% Remember to delete \cygwin\bin\link.exe and \cygwin\bin\cc.exe. Link.exe gets confused with the Visual C++ linker. cc.exe causes a crash in ntvdm.exe when building cm3cg (at least outside of Cygwin). gcc.exe works fine and suffices. vcvars32 has been run so cl.exe, link.exe are in %PATH%, %LIB%, and %INCLUDE% are set I'd actually like to simplify that, there is prototype code already in pylib.py. This is for bootstrapping. It shouldn't be needed once there is a binary distribution to start with. You should also be able to bootstrap from other hosts, but I haven't tried. No other variables are needed. No CM3_ROOT, CM3_INSTALL, or M3_CONFIG. First make sure you have an up to date NT386 toolset: cd C:\dev2\cm3.2\scripts\python upgrade.py once that finishes set CM3_OSTYPE=POSIX (again remember no trailing spaces..) do-cm3-all.py realclean do-cm3-front.py buildship install-cm3-compiler.py do-cm3-std.py buildship do-cm3-std will eventually hit a crash, but this is after it has gotten quite far. To verify you are really using Cygwin: findstr /i /m cygwin1.dll \cm3\bin\* \cm3\bin\cm3.exe (This is what means you are /using/ it, the others maybe aren't run.) \cm3\bin\arithmetic.dll \cm3\bin\BitVector.dll \cm3\bin\cm3cg.exe \cm3\bin\DiGraph.dll \cm3\bin\Geometry.dll \cm3\bin\m3.dll \cm3\bin\m3bundle.exe \cm3\bin\m3core.dll \cm3\bin\m3parseparams.dll \cm3\bin\m3slisp.dll \cm3\bin\mklib.exe \cm3\bin\patternmatching.dll \cm3\bin\set.dll \cm3\bin\SortedTableExtras.dll \cm3\bin\sysutils.dll \cm3\bin\table-list.dll \cm3\bin\TempFiles.dll Or watch .dll loads in a debugger: \bin\cdb \cm3\bin\cm3 ModLoad: 00400000 01212000 image00400000 ModLoad: 7c900000 7c9b0000 ntdll.dll ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll ModLoad: 61000000 61200000 C:\cygwin\bin\cygwin1.dll <<< ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL ModLoad: 77e70000 77f02000 C:\WINDOWS\system32\RPCRT4.dll - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 14:50:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:50:50 +0000 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: I guess really this is why "I" will use NT386 or NT386MINGNU, and "you" will use NT386GNU. NT386GNU should be counter whatever I like. :) Ok, I'll try that again.. (So much for those instructions I just sent out, oh well; they are still correct but after some testing..may be invalidated..) I did find that Cygwin->cm3->quake->exec("c:\cm3\bin\m3bundle") doesn't work due to these annoying path issues... - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sat, 23 Feb 2008 13:07:09 +0000Subject: Re: [M3devel] paths.. They'll be escaped.?Olaf, I'm just not sure. It could be that if I just set CM3_ROOT, CM3_INSTALL, and possibly M3_CONFIG, then the Posix code is ok. However, note as I said that Cygwin does accept these paths..The opposite problem holds too -- I like copy/pasting the error messages into file.open dialogs, and forward slashes don't work there unfortunately.I had a diff for a bit that between \ and /, would try to use whatever was already in the data.I had a problem with but it still might be viable, specifically in the Win32 paths. Maybe if I can just get it definitely usable (maybe already there) and get a distribution out, someone else can hack on this issue.. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Jay,> > I'm not really happy with NT386GNU using PathnameWin32.m3.> In my opininion it should just use the POSIX code, whatever problems> people will have with their installation roots. (These can be avoided> by using the /cygdrive/... equivalents.)> Why don't we just assume that by deafult CM3 is installed in> /usr/local/cm3 as for all other targets (except NT386, of course)?> > One thing that immediately comes to mind is that all paths output> by CM3 programs will contain \ instead of / then and thus be> unusable for simple copy-and-paste, as \ is the escape character> in all POSIX command line tools. So this seems kind of incompatible> to me.> > Olaf> > Quoting Jay :> > > I could be wrong about many things here:> >> > Cygwin fopen and I presume open accepts all of:> > c:\foo, c:/foo, /foo, \foo> >> > /foo and \foo probably have a different meaning between Cygwin and Win32.> > In Win32, /foo and \foo are, well, \foo, on the current drive.> > In Cygwin, /foo is probably /foo at the Cygwin root.> > I'd kind of like to be wrong here, about \foo having different > > meanings between them, since it a common form for me.> >> > Cygwin does not accept c:foo.> > In Win32 c:foo is foo in the current working directory of the C: drive.> > I don't think c:foo is used often, but it does have a meaning.> >> > Now, as well, cm3 has its own Path module, M3Path, but I realized > > tonight it also uses libm3's Pathname module a fair amount. In > > particular, I was having errors "shipping".> >> > This throws a big monkey wrench into where I was going.> > So now, after a bunch of going back and forth on various uncommited > > changes, I have now switched (and commited) NT386GNU to use > > PathnameWin32.m3. To some extent, this strikes at the core of "what > > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > > However, remember that Cygwin does appear to accept Win32 paths. > > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > > Win32 accepts /foo, is it Posix?) As well, this target still uses > > cygwin1.dll for its all its odd behaviors. It still uses > > open/read/write (again, remember that msvcrt.dll DOES expose these > > SAME functions..I still contend that Win32 is close enough to Posix > > to satisfy almost everyone..and then X Windows can be dealt with > > separately maybe, or Trestle/Win32 fixed).> >> > I have some more testing to do but I think this switch will fly, and > > various other options can go away.> > And I can undo the small amount I had commited.> > I think I'll just send my m3path.m3 diff around and then delete it.> >> > I ended up with a set based approach where host and target have a > > set of dir separaters, volume separaters, and separators (union of > > previous two). These are TINY sets, containing a maximum of three > > characters each, and '/' is always a member of two of them. So a set > > is kind of overkill. But it works out pretty ok.> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 23 15:35:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 23 Feb 2008 09:35:49 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF1F8F.1E75.00D7.1@scires.com> References: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> <47BF1F8F.1E75.00D7.1@scires.com> Message-ID: <8796B54C-B731-4042-9A86-D14368601CF9@cs.purdue.edu> Yes, Blair MacIntyre is still at GaTech: http://www.cc.gatech.edu/ ~blair/home.html. On Feb 22, 2008, at 7:16 PM, Randy Coleburn wrote: > Mika: > > I believe the person you are referencing is Blair McIntyre. Last > time I communicated with him he was a professor at Georgia Tech. > > Regards, > Randy > > >>> Mika Nystrom 2/22/2008 4:19 PM >>> > Oh I should be clear on what I mean, exactly, when I say things > like that. > > Pickles "version 1", what was in SRC M3 and is in PM3, were never > from what > I understand completely implemented? For one thing, they didn't > support > endian-switching. > > A gentleman with a Scottish name that eludes me at the moment came > out with "Pickles version 2", which do the endianness-switching, among > other things. > > My "PM3" includes a lot of things from newer M3s, such as this > Pickles version 2. > > I really am not enamored with my ancient PM3. I just need something > that works reliably on Cygwin *and* FreeBSD (which it does). So > adding > the odd CM3 library to it is no big deal. > > But the TEXT issue is so deeply embedded in the compiler and runtime > that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or > vice versa. > > I am almost certain I have tested interchanging pickles between my > PM3 code > and some CM3 code and verified that it did work as long as there > were no > TEXTs involved. (It was a couple of years ago I did this; I think > I spammed > m3devel about it then too.) > > Mika > > "Rodney M. Bates" writes: > >I believe from reading code, that PM3 and CM3 pickle files are non- > interchangeable > >for another, more serious reason, namely, that the byte ordering > of type > >signatures in the files is different. > > > >I think this can be fixed by making pickle code try either byte > ordering, without > >invalidating any existing pickle files. There would be a very > remote chance of > >a misrecognized type, but then this is already possible due to the > hash-code nature > of signatures anyway. This is on my to-do list for work on pickles. > > > >Mika Nystrom wrote: > >> Ugh!!! I am still using compilers that are almost ten years old > >> on ALL my systems just because I need to share pickles between them > >> and CM3 has a different TEXT format from my ancient PM3. Tony > >> thinks there's a workaround with specials but I haven't had a > chance > >> to get to it yet... > >> > >> > >> > >-- > >------------------------------------------------------------- > >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 Sat Feb 23 16:04:39 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:04:39 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: I see a lot of like: == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ --- building in NT386GNU --- ignoring ../src/m3overrides new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: synwr.lib--- shipping from NT386GNU --- This is mildly dumb. I should check as to why m3.lib changed, but an import .lib changing is rarely legitimate cause for a relink. As long as no symbols were added or removed, no relink is needed. Even then, it usually doesn't matter, but harder to tell. It's true the import .libs have "hints" as to "ordinals" but I don't think anyone cares about those. Definitely maybe the fix should be that when the import .lib is made, if the list of symbols exported is identical to the previous version, don't update the file. - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:27:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:27:59 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> I think cm3 reacts conservative if an imported library changes because programs may be built standalone. A possible optimization would be to check if the symbols are still the same (as you suggested) and avoid the re-link in case of building shared (but not if building standalone, as the symbols may be the same, but the code has changed). Olaf Quoting Jay : > I see a lot of like: > > == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build > -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] > +++ > --- building in NT386GNU --- > > ignoring ../src/m3overrides > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib > *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo > SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared > -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: > synwr.lib--- shipping from NT386GNU --- > > This is mildly dumb. > I should check as to why m3.lib changed, but an import .lib changing > is rarely legitimate cause for a relink. > As long as no symbols were added or removed, no relink is needed. > Even then, it usually doesn't matter, but harder to tell. > > It's true the import .libs have "hints" as to "ordinals" but I don't > think anyone cares about those. > > Definitely maybe the fix should be that when the import .lib is > made, if the list of symbols exported is identical to the previous > version, don't update the file. > > - Jay > _________________________________________________________________ > Connect and share in new ways with Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 16:32:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:32:16 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> Message-ID: Granted, just given a file path and a timestamp -- don't know if it is an import .lib or not. Either takes more smarts on the consumer, or I think more likely, more smarts on the producer. At least on Windows, the .objs within an import .lib are easily discernable as the special import type and not containing static code. You can actually have hybrid .libs. For example msvcrt.lib contains mostly imports but also static startup code (thus no need for crt0.o or such). Anyway, I think the smarts belong in the producer as that is what would lead to less i/o. I'm starting to need a bug database. :) e.g. cleanup this redundancy: C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.m3(226): tm := localtime(ADR(secs))^ C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; (make ANSI time.h available on Win32 also, if it helps) - Jay > Date: Sat, 23 Feb 2008 16:27:59 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] unnecessary relinks when import libs change> > I think cm3 reacts conservative if an imported library changes> because programs may be built standalone. A possible optimization> would be to check if the symbols are still the same (as you suggested)> and avoid the re-link in case of building shared (but not if building> standalone, as the symbols may be the same, but the code has changed).> > Olaf> > Quoting Jay :> > > I see a lot of like:> >> > == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build > > -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > > 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] > > +++> > --- building in NT386GNU ---> >> > ignoring ../src/m3overrides> > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib > > *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo > > SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared > > -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: > > synwr.lib--- shipping from NT386GNU ---> >> > This is mildly dumb.> > I should check as to why m3.lib changed, but an import .lib changing > > is rarely legitimate cause for a relink.> > As long as no symbols were added or removed, no relink is needed.> > Even then, it usually doesn't matter, but harder to tell.> >> > It's true the import .libs have "hints" as to "ordinals" but I don't > > think anyone cares about those.> >> > Definitely maybe the fix should be that when the import .lib is > > made, if the list of symbols exported is identical to the previous > > version, don't update the file.> >> > - Jay> > _________________________________________________________________> > Connect and share in new ways with Windows Live.> > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 16:38:18 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:38:18 +0000 Subject: [M3devel] response file changes? In-Reply-To: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: Nobody should depend on this strange heuristic-based behavior.. I know that doesn't make it so, but it does possibly legitimize changing it. > as long as their names are unique. Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt. I wrap around from 9 to 0 because Quake can't do math. In practise there's only ever one or two response files per directory, one to make in import .lib and one make a .dll, or just one to link an .exe. C compilation doesn't use response files, but it could if the parameters got long and esp. if there were lots of C files in one directory and batch compile them instead of one at a time.. That's a nice optimization in C-based systems, not a big deal in Modula-3 with so few .c files. Maybe soon I'll rip out my code, and then fix the reliable deletion, and THEN move the directory... - Jay > Date: Sat, 23 Feb 2008 12:04:46 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] response file changes?> > Two short comments:> > o Response files in the target directory should be OK, as long as> their names are unique.> > o The heuristic is built-in to arglist(pfx, array), IIRC; I wouldn't> change that without need. You never know what depends on it, as it> has been there for a long time.> > Olaf> > Quoting Jay :> > > "response files" are files that contain command lines, to > > overcomecommand line length limits. (Why the limits are so small? > > Lame.)> > CM3 has built in support for them.> > I have seen them not be deleted reliably.> > While the deletion should be made more reliable, I propose they be > > writteninto the target directory instead of "temp".> > That is, nearly all writes should be into the target directory.This > > is what is reliably cleaned up when you run "realclean".> >> > I realize there is a tension between putting things that belong > > together together, and reliable deletion, vs. load balancing of I/O. > > "Temp" is sometimes smaller/faster.> > I had already worked around this by wrapping up the response file > > supportin Quake code that moves the file into the target directory > > immediatelyafter creating it. I'll be able to remove that code, and > > live with theunreliably deleted files only when using older tools.> > ?> > Also, the built in support uses a heuristic.For shorter command > > lines, it doesn't use a response file.I found that surprising and a > > bit disappointing.While a more immediately readable log is valuable, > > consistency is too.> > Leave it alone or make it always use a response file?> > The Microsoft C compiler and linker dump the output of any response > > filethey are given, so that gets you a readable log.> >> > I don't care all that much.> > Maybe I'll just look into why the deletion is unreliable, but I > > figure "cleanup" is always unreliable because you might control-c > > the build, or the compiler might crash, etc. There is a "delete on > > close" flag in Windows, but I think it has a problem in that you > > have to keep the file open and if anyone else also opens it, they > > might need file_share_delete, not sure. File_share_delete not being > > supported on Win9x, maybe not much used?> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:40:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:40:52 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> Message-ID: <20080223164052.lswpp1pc4ksgwwkw@mail.elegosoft.com> Quoting Jay : > Granted, just given a file path and a timestamp -- don't know if it > is an import .lib or not. > Either takes more smarts on the consumer, or I think more likely, > more smarts on the producer. > At least on Windows, the .objs within an import .lib are easily > discernable as the special import type and not containing static > code. You can actually have hybrid .libs. For example msvcrt.lib > contains mostly imports but also static startup code (thus no need > for crt0.o or such). Anyway, I think the smarts belong in the > producer as that is what would lead to less i/o. > > I'm starting to need a bug database. :) We've got one, but it's not externally accessible, and hasn't been used much recently. I've already discussed this topic with others at elego, and we'll setup something during the next weeks (hopefully). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 16:42:53 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:42:53 +0000 Subject: [M3devel] response file changes? In-Reply-To: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: truncated again... "rip out my code" btw is Quake code in the NT386 config files (and also similar in m3cc and m3gdb on Windows platforms) - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] response file changes?Date: Sat, 23 Feb 2008 15:38:18 +0000 Nobody should depend on this strange heuristic-based behavior..I know that doesn't make it so, but it does possibly legitimize changing it. > as long as their names are unique. Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt.I wrap around from 9 to 0 because Quake can't do math.In practise there's only ever one or two response files per directory, one to make in import .lib and one make a .dll, or just one to link an .exe.C compilation doesn't use response files, but it could if the parameters got long and esp. if there were lots of C files in one directory and batch compile them instead of one at a time.. That's a nice optimization in C-based systems, not a big deal in Modula-3 with so few .c files. Maybe soon I'll rip out my code, and then fix the reliable deletion, and THEN move the directory... - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 16:47:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:47:50 +0000 Subject: [M3devel] paths.. In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: oky doky it's back to Posix, and pylib.py sniffs cm3.exe to see which it wants...seems to be working pretty ok.. and I still don't need to set those pesky environment variables phew. :) If I can just push out a make-dist output maybe someone will load balance? I still think some things could be improved a bit in terms of knowing or probing host and target behavior. You know, OS_TYPE is target, not host. I cheat and use the OS environment variable, which is Windows_NT on Windows (ignoring 9x). Pushing more stuff into Modula-3 -- "expanding the portable host" -- a la sysutils, definitely helps. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> > I'm not really happy with NT386GNU using PathnameWin32.m3. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:52:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:52:06 +0100 Subject: [M3devel] response file changes? In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: <20080223165206.mna5tqyi2o0kokg0@mail.elegosoft.com> Quoting Jay : > Nobody should depend on this strange heuristic-based behavior.. > I know that doesn't make it so, but it does possibly legitimize changing it. OK, probably you're right there. > > as long as their names are unique. > > Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt. > I wrap around from 9 to 0 because Quake can't do math. > In practise there's only ever one or two response files per > directory, one to make in import .lib and one make a .dll, or just > one to link an .exe. We could just add a function to create a unique tmpfile name in a given directory to quake. There's the tempfiles package in m3-libs. Olaf > C compilation doesn't use response files, but it could if the > parameters got long and esp. if there were lots of C files in one > directory and batch compile them instead of one at a time.. That's a > nice optimization in C-based systems, not a big deal in Modula-3 > with so few .c files. > > Maybe soon I'll rip out my code, and then fix the reliable deletion, > and THEN move the directory... > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Feb 23 17:24:29 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 23 Feb 2008 11:24:29 -0500 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Why @M3novm? That should no longer be needed. On Feb 23, 2008, at 10:04 AM, Jay wrote: > I see a lot of like: > > == package C:\\dev2\\cm3.2\m3-obliq\synloc == > +++ ['cm3.exe -build -keep -DROOT=/C/dev2/cm3.2 - > DCM3_VERSION_TEXT=d5.6.0 -DCM3 > _VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > 'cm3.exe -ship -k > eep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 - > DCM3_VERSION_NUMBER=050600 - > DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ > > --- building in NT386GNU --- > > ignoring ../src/m3overrides > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving > synwr.lib *** This line **** > mklib -out:synwr.lib SynWr.io SynWr.mo SynLocation.io > SynLocation.mo 2>&1 > sy > nwr.lst > gcc -shared -Wl, at _m3responsefile1.txt 2>&1 > synwr.lst > Creating library file: synwr.lib > --- shipping from NT386GNU --- > > This is mildly dumb. > I should check as to why m3.lib changed, but an import .lib > changing is rarely legitimate cause for a relink. > As long as no symbols were added or removed, no relink is needed. > Even then, it usually doesn't matter, but harder to tell. > > It's true the import .libs have "hints" as to "ordinals" but I > don't think anyone cares about those. > > Definitely maybe the fix should be that when the import .lib is > made, if the list of symbols exported is identical to the previous > version, don't update the file. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Sat Feb 23 17:42:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 16:42:27 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: For bootstrapping from older tools. I have one set of configuration files (the checked in ones) that don't require any editing and do whatever runtime probing is needed (such as for the gc wrap flags on PPC_LINUX). I have a consistent crash building with older tools that I wasn't able to debug or otherwise workaround. On Windows I occasionally start over from 5.1.8. 5.1.3 would work but sysutils can't be compiled against its runtime. I was going to see about booting from 4.1 or 3.6 but I figure no go for the same reason. I've asked but no answer as to what people think about buildability with older tools. Probably it's not a valuable battle, otherwise progress is blocked. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] unnecessary relinks when import libs change> Date: Sat, 23 Feb 2008 11:24:29 -0500> To: jayk123 at hotmail.com> > Why @M3novm? That should no longer be needed. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sat Feb 23 18:31:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 23 Feb 2008 11:31:36 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> Message-ID: <47C05878.1050101@wichita.edu> I guess I misunderstood. I had the idea from the quoted text below that MAC OS X needed a mixture of lazy and strict alignment. If every platform uses the same alignment rules for all types of all programs on the platform, then the alignment rule property can just be made an additional field of the RTPacking.T. This is much easier to do without compatibility problems, because this value is encoded in bits in a 32-bit word in pickle headers, with unused bits that are now ignored. The alignment strategy could just be in another bit. From a post on 2-11: --------------------------------------------------------------------------------------------------------- That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for historical reasons. All other structures should use normal alignment to be compatible with C and Unix interfaces. The alignment change was implemented to be supported only in packed structures as a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly restrictive alignment rules in packed structures. On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > It sounds like all that Mac OS X needs is for _all_ types in an entire > program to use the liberal packing rules. Have I understood correctly? > I would have no grief over that. --------------------------------------------------------------------------------------------------------- Darko wrote: > The alignment rules are particular to a platform, not a type (at least > after we get rid of the pragma), so is there no field where we can > encode some information about the platform in the pickle header or > something? Where is endian stored? > > -- ------------------------------------------------------------- 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 Sat Feb 23 18:36:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 17:36:12 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: scripts\pylib.py: ## workaround crash when booting from 5.1.3 that is# difficult to debug -- crashes earlier in debugger# without this switch, no repro with this switch## This has no effect with current tools/libraries.#DEFS += " @M3novm" From: jayk123 at hotmail.com.. > From: hosking at cs.purdue.edu> > Why @M3novm? That should no longer be needed. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 18:40:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 18:40:25 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: <20080223184025.arvp8z5lc8ww4wgg@mail.elegosoft.com> Quoting Jay : > On Windows I occasionally start over from 5.1.8. > 5.1.3 would work but sysutils can't be compiled against its runtime. > I was going to see about booting from 4.1 or 3.6 but I figure no go > for the same reason. That's probably because modules have been added to m3core and libm3. > I've asked but no answer as to what people think about buildability > with older tools. > Probably it's not a valuable battle, otherwise progress is blocked. I don't think it's worth the efforts to try to remain boot-compatible with all older versions of M3. We can still use cross-compilation if there's dire need. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 19:11:29 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 18:11:29 +0000 Subject: [M3devel] NT386GNU distribution available (Cygwin this time) In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: birch: /var/www/modula3.elegosoft.com/cm3/uploaded-archives Now has cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 It doesn't appear on http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html This is a "Cygwin" based release.(From now on, the older MinGWin-based target will probably be called NT386MINGNU,though there are archives out there named "NT386GNU" that are MinGWin-based). It extracts like: tar xfj cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 cm3-min-POSIX-NT386GNU-d5.6.0/bin/cm3.cfg cm3-min-POSIX-NT386GNU-d5.6.0/bin/cm3.exe ... and then you rename or copy to \cm3 or /usr/local/cm3 or whatever. If you are using scripts\python\*, then set CM3_OSTYPE=POSIX and everything else should be figured out. TBD: If cl.exe/link.exe aren't on the path, then setting CM3_OSTYPE ought not be necessary. Sniffing uname and gcc -v should suffice. But that isn't the case yet. This distribution also includes the config files for NT386 and NT386MINGNU and should be able to target them. You can edit the one line cm3.cfg. I didn't test that aspect. (Really, if you build the cross gcc/ld tools, any cm3 can target any target.) A reasonable way to go is thus: tar xvj cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 rmdir /q/s \cm3 xcopy /fivery cm3-min-POSIX-NT386GNU-d5.6.0 \cm3 set PATH=c:\cm3\bin;c:\cygwin\bin;%PATH% cd \dev2\cm3.2\scripts\python upgrade do-cm3-all realclean do-cm3-std buildship It will error eventually, but after building a lot. Anyone game to try it and report back? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 19:26:55 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 18:26:55 +0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47C05878.1050101@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> Message-ID: kind of obnoxious of me here sorry: I am not volunteering to do any work here. :) I propose that declaration that interface with C be declared PACKED (if that even exists) or BITS n FOR (I know that exists; it was pointed out to me and I have been using it). I would like to be able to say BYTES n FOR, but ok, I say BITS n * 8 FOR. I propose there be a command line switch, or interface/module-level pragma that issues warnings or errors for any apparent need to insert any padding. I propose that any padding for alignment that is needed to interface with existing C code be explicitly inserted. I propose that when you say BITS n FOR, you be able to get a warning/error if the size isn't exactly right. I know it is already an error today if the size is too small, but I assume the compiler will grow the type to fit if it is "too big" and I'd rather not have that. On the other hand, while I have been using BITS n FOR, I make up an arbitrary type. That is, I say: Foo = BITS exact FOR RECORD blah blah pad : BITS exact FOR arbitrary small type such as [0..0] END; While I don't want the compiler to expand Foo up to exact, I don't care about the [0..0] thing. I guess in the interest of being less lazy and coming up with a simpler feature set, I am willing to be more precise in the padding. Or maybe a new type can be invented BITS exact for Padding. And maybe you can tack on ":= 0" to it, no matter the size. (Notice how in the socket code, the type of the padding can't be changed willy nilly because there is code to zero initialize it; seems a little bit lame to me.) I would probably volunteer to do some of the header repair here. Alignment issues bother me and I think we might be in a position to solve them once and for all for Modula-3, in a reasonable simple, clear, reliable, multi-target way. Part of this proposal would need to distinguish at least three scenarios: exact layout for interfacing with existing C stable layout for interface with self -- declare some new type in Modula-3 that I can pickle on multiple platforms but which Modula-3 can determine the layout of; padding can be inserted here but it must be the same across various time/space/configuration don't care layout for data that will only ever be in memory and shared amongst code built by the same basic compiler with the same declarations; padding can be inserted here and vary from build to build or such another case: exact layout for interfacing with existing Modula-3/pickles. Or maybe simply pickles need persisted metadata about the various fields, offsets, sizes? I have never used pickles or looked at the code... - Jay > Date: Sat, 23 Feb 2008 11:31:36 -0600> From: rodney.bates at wichita.edu> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] <*LAZYALIGN*>> > I guess I misunderstood. I had the idea from the quoted text below that MAC OS X needed a mixture> of lazy and strict alignment. If every platform uses the same alignment rules for all types of all> programs on the platform, then the alignment rule property can just be made an additional field of> the RTPacking.T.> > This is much easier to do without compatibility problems, because this value is encoded in bits> in a 32-bit word in pickle headers, with unused bits that are now ignored. The alignment strategy> could just be in another bit.> > > From a post on 2-11:> ---------------------------------------------------------------------------------------------------------> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for > historical reasons. All other structures should use normal alignment to be compatible with C and > Unix interfaces. The alignment change was implemented to be supported only in packed structures as > a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly > restrictive alignment rules in packed structures.> > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:> > > It sounds like all that Mac OS X needs is for _all_ types in an entire> > program to use the liberal packing rules. Have I understood correctly?> > I would have no grief over that.> ---------------------------------------------------------------------------------------------------------> > Darko wrote:> > The alignment rules are particular to a platform, not a type (at least > > after we get rid of the pragma), so is there no field where we can > > encode some information about the platform in the pickle header or > > something? Where is endian stored?> > > > > -- > -------------------------------------------------------------> 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 _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 20:29:11 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 20:29:11 +0100 Subject: [M3devel] NT386GNU distribution available (Cygwin this time) In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: <20080223202911.ca9eq2e74kwcgwck@mail.elegosoft.com> Quoting Jay : > birch: /var/www/modula3.elegosoft.com/cm3/uploaded-archives > Now has cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 > It doesn't appear on > http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html This is because it is no `daily snapshot'. Daily snapshots are built by the daily regression runs. Uploaded files appear on http://www.opencm3.net/ --> Installation --> Uploaded Archives: http://www.opencm3.net/uploaded-archives/index.html :-) You could also add the description from your email as one of cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2.{README,txt,html} and an appropriate link will be shown on the page. The index is updated every 30 minutes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 21:03:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 21:03:23 +0100 Subject: [M3devel] CM3 Tinderbox Display Message-ID: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> I've made some changes to the tinderbox display: 1. The last 48 hours are displayed by default now. 2. I switched the display mode from build-event time to event time. In build-event time (which is more compact), current build records were often not displayed for unknown reasons. Someone with more perl knowlege must look into this (Ronny?) With event time granularity, we get an entry for every CVS checkin, too. 3. I changed the VC switch in DBImpl from 'TinderDB::VC_Bonsai' to 'TinderDB::VC_CVS'. This seems to give us some entries in the Guilty column. The previous build time in the pop-ups is still broken, so that the Bonsai queries for `check-ins since last build' don't work. I also disabled some suspicious db deletes in the perl code, which may have been responsible for the loss of data we've seen (I386_DARWIN, for example). BTW, is there a Perl guru on this list who could fix things faster than me? (Our administrator cannot spend too much time for this stuff, and Kaspar seems still to be bound by his studies.) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 21:28:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 20:28:32 +0000 Subject: [M3devel] CM3 Tinderbox Display In-Reply-To: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: I'm so-so with Perl..but way out of context, and not done any database stuff in any domain...have started trying to run the tinderbox and regression tests today..some luck running the tests, not much with tinderbox yet..I got it to do the cvs checkout, and I extracted my archive where it wanted it..got as far as: $ ( . defs.sh ; test_build_core_rel )hostname: invalid option -- sTry `hostname --help' for more information.TESTHOSTNAME=WS=/home/Jay/work/cm3-ws/-2008-02-23-20-23-57LASTREL=5.4.0INSTROOT_REL=/home/Jay/work/cm3-inst//rel-5.4.0INSTROOT_POK=/home/Jay/work/cm3-inst//prev-okINSTROOT_LOK=/home/Jay/work/cm3-inst//last-okINSTROOT_CUR=/home/Jay/work/cm3-inst//currentCM3_OSTYPE=WIN32CM3_TARGET=NT386BINDISTMIN=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2CM3CVSSERVER=jkrell at m3.elegosoft.comCM3CVSROOT=:ext:jkrell at m3.elegosoft.com:/usr/cvsBINDISTMIN_NAME=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2BINDISTMIN=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2testing ssh jkrell at m3.elegosoft.com..ssh jkrell at m3.elegosoft.com ok === 2008-02-23 20:24:01 build cm3 core in /home/Jay/work/cm3-ws/-2008-02-23-20-23-57 with last release /home/Jay/work/cm3-inst//rel-5.4.0Critical Mass Modula-3 version d5.6.0 last updated: 2008-01-31 compiled: 2008-02-23 17:41:32 configuration: /home/Jay/work/cm3-inst//current/bin/cm3.cfg bash: cd: /home/Jay/work/cm3-ws/-2008-02-23-20-23-57/cm3: No such file or directorygotta run for a while. - Jay > Date: Sat, 23 Feb 2008 21:03:23 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> CC: m3-support at elegosoft.com; tobermueller at elegosoft.com> Subject: [M3devel] CM3 Tinderbox Display> > I've made some changes to the tinderbox display:> > 1. The last 48 hours are displayed by default now.> > 2. I switched the display mode from build-event time to> event time. In build-event time (which is more compact),> current build records were often not displayed for unknown> reasons. Someone with more perl knowlege must look into this> (Ronny?) With event time granularity, we get an entry for> every CVS checkin, too.> > 3. I changed the VC switch in DBImpl from 'TinderDB::VC_Bonsai' to> 'TinderDB::VC_CVS'. This seems to give us some entries in the> Guilty column.> > The previous build time in the pop-ups is still broken, so that> the Bonsai queries for `check-ins since last build' don't work.> > I also disabled some suspicious db deletes in the perl code,> which may have been responsible for the loss of data we've seen> (I386_DARWIN, for example).> > BTW, is there a Perl guru on this list who could fix things faster> than me? (Our administrator cannot spend too much time for this stuff,> and Kaspar seems still to be bound by his studies.)> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 24 01:01:05 2008 From: darko at darko.org (Darko) Date: Sun, 24 Feb 2008 11:01:05 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47C05878.1050101@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> Message-ID: <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> What I meant to say below is that unpacked structures are aligned according to the normal rules under Darwin. The problem is that the packed alignment rules without the change are too restrictive. On 24/02/2008, at 4:31 AM, Rodney M. Bates wrote: > I guess I misunderstood. I had the idea from the quoted text below > that MAC OS X needed a mixture > of lazy and strict alignment. If every platform uses the same > alignment rules for all types of all > programs on the platform, then the alignment rule property can just > be made an additional field of > the RTPacking.T. > > This is much easier to do without compatibility problems, because > this value is encoded in bits > in a 32-bit word in pickle headers, with unused bits that are now > ignored. The alignment strategy > could just be in another bit. > > > From a post on 2-11: > --------------------------------------------------------------------------------------------------------- > That's not quite right. Certain Mac API structures need to be > aligned to Motorola 68K alignment for historical reasons. All other > structures should use normal alignment to be compatible with C and > Unix interfaces. The alignment change was implemented to be > supported only in packed structures as a natural and intuitive way > to "force" alignment. You could view it as a bug fix to overly > restrictive alignment rules in packed structures. > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > > > It sounds like all that Mac OS X needs is for _all_ types in an > entire > > program to use the liberal packing rules. Have I understood > correctly? > > I would have no grief over that. > --------------------------------------------------------------------------------------------------------- > > Darko wrote: >> The alignment rules are particular to a platform, not a type (at >> least after we get rid of the pragma), so is there no field where >> we can encode some information about the platform in the pickle >> header or something? Where is endian stored? > -- > ------------------------------------------------------------- > 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 Feb 24 01:22:29 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 00:22:29 +0000 Subject: [M3devel] exposing both path name types? In-Reply-To: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: What is the idiom for this: Currently: There is Pathname.i3. PathnamePosix EXPORTS Pathname PathnameWin32 EXPORTS Pathname You can only have one in a link. It would seem possibly useful to have: Pathname.i3 unchanged PathnamePosix.i3 identical to Pathname.i3 (some what to avoid the duplication?) PathnameWin32.i3 identical to Pathname.i3 (ditto) On Posix targets: PathnameWin32.m3 exports just PathnameWin32 PathnamePosix exports both PathnamePosix and Pathname On Windows targets: PathnamePosix exports just PathnamePosix PathnameWin32 exports both PathnameWin32 and Pathname That is Pathname.Foo resolves statically at compile time to the target-specific library. PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. These modules each import nothing, except Text. They do all their string manipulation themselves. Olaf's recent Quake extensions document but don't implement pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> text As long as pn is a fullpath, these are easy, I just wrote up prototypes, haven't compiled them. I think these functions might suggest doing what I'm asking about as well, maybe. Or maybe you'd just convert and then never pick back apart. I have sleazed by for now by using subst_text / to \ and setting up NTFS junctions. In this way, I can cross build NT386 <=> NT386GNU either host, either target. Had I not done anything, the linker interprets /cygdrive/c/foo/bar.lib as a command switch and says it doesn't understand it. Not a big deal, but I think there might be some easy progress here. This is not just about Pathname. It is also about File. Even though NT386GNU File is FilePosix, it would be useful to allow the serial package to use FileWin32 instead. But FilePosix and FileWin32 both reveal the same types. It'd be nice if they could expose FilePosix.T and FileWin32.T and then only one of them reveal File.T = FilePosix.T or File.T = FileWin32.T, something like that. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 24 01:34:13 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 00:34:13 +0000 Subject: [M3devel] exposing both path name types? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: Oh I think I see some of how to do this. Olaf's path stuff is actually implemented, maybe just not exposed, and perhaps incomplete, but it demonstrates a "trick" of Modula-3. You can do this: INTERFACE I; PROCEDURE F1(); PROCEDURE F2(); END I; MODULE A EXPORTS I; PRODEDURE F1() = ... END F1; MODULE B EXPORTS I; PRODEDURE F2() = ... END F2; The implementation of interface can be distributed among multiple modules. To export an interface just means to implement some or all of it. Usually but not necessarily all. (I wonder what if you implement none of it?) That helps much. It doesn't provide a complete idiom I think for what I ask, but it is a start. I suspect generics help here. But I'm still not sure what the entire answer is. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sun, 24 Feb 2008 00:22:29 +0000Subject: [M3devel] exposing both path name types? What is the idiom for this: Currently:There is Pathname.i3.PathnamePosix EXPORTS PathnamePathnameWin32 EXPORTS PathnameYou can only have one in a link. It would seem possibly useful to have:Pathname.i3 unchangedPathnamePosix.i3 identical to Pathname.i3 (some what to avoid the duplication?)PathnameWin32.i3 identical to Pathname.i3 (ditto) On Posix targets: PathnameWin32.m3 exports just PathnameWin32 PathnamePosix exports both PathnamePosix and Pathname On Windows targets: PathnamePosix exports just PathnamePosix PathnameWin32 exports both PathnameWin32 and Pathname That is Pathname.Foo resolves statically at compile time to the target-specific library.PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. These modules each import nothing, except Text. They do all their string manipulation themselves. Olaf's recent Quake extensions document but don't implement pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> textAs long as pn is a fullpath, these are easy, I just wrote up prototypes, haven't compiled them. I think these functions might suggest doing what I'm asking about as well, maybe.Or maybe you'd just convert and then never pick back apart. I have sleazed by for now by using subst_text / to \ and setting up NTFS junctions.In this way, I can cross build NT386 <=> NT386GNU either host, either target.Had I not done anything, the linker interprets /cygdrive/c/foo/bar.lib as a command switch and says it doesn't understand it.Not a big deal, but I think there might be some easy progress here. This is not just about Pathname. It is also about File.Even though NT386GNU File is FilePosix, it would be useful to allow the serial package to use FileWin32 instead.But FilePosix and FileWin32 both reveal the same types.It'd be nice if they could expose FilePosix.T and FileWin32.T and then only one of them reveal File.T = FilePosix.T or File.T = FileWin32.T, something like that. - Jay Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 24 01:59:03 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 24 Feb 2008 01:59:03 +0100 Subject: [M3devel] Do I remember well... Message-ID: <1203814743.7865.25.camel@hias.m3w.org> Once, there was a talk about (original?) CM3 making checked runtime errors behave like exceptions? -- Dragi?a Duri? From wagner at elegosoft.com Sun Feb 24 02:19:34 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 02:19:34 +0100 Subject: [M3devel] Do I remember well... In-Reply-To: <1203814743.7865.25.camel@hias.m3w.org> References: <1203814743.7865.25.camel@hias.m3w.org> Message-ID: <20080224021934.ll0vw5k2swoooccs@mail.elegosoft.com> Quoting Dragi?a Duri? : > Once, there was a talk about (original?) CM3 making checked runtime > errors behave like exceptions? Yes. See http://www.opencm3.net/about-cm3.html: o <*IMPLICIT*> exceptions (changes language semantics) o checked runtime errors are mapped to the implicit exception RuntimeError.E I don't think anything has changed in this area. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 24 12:03:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 11:03:34 +0000 Subject: [M3devel] another nt/posix target? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: This is really getting a head of things, but I think maybe there should be a target for "Services for Unix". Probably called X86_INTERIX or something? Or X86_INTERIX_GCC and X86_INTERIX_MSVC? Or X86_SFU_GNU, X86_SFU_MS? Or simply X86_NTX? I think the different tools might not matter -- might be just "cc" vs. "gcc" and the same runtime, same setjmp buffer. It looks like you have a choice of compilers. It looks like a pretty good system from a Posix point of view. I have to try it out more. And maybe stay on other areas for now. Pthreads looks definitely viable here, so start with the Cygwin "minimized" "headers" (.i3) files, correct them, add back pthreads (and dependent signal stuf..) I know it's too late, but I guess naming scheme should have included "OS_TYPE". X86_WIN32_MSVC X86_WIN32_BLAND (Borland) X86_WIN32_DMARS (Digital Mars) X86_WIN32_WAT (Open Watcom) X86_WIN32_GCC (MinGWin) or maybe clearer X86_WIN32_MINGWIN X86_POSIX_GCC (Cygwin) or maybe clearer X86_POSIX_CYGWIN X86_POSIX_SFU or X86_POSIX_INTERIX or X86_POSIX_INTERIX_GCC or X86_POSIX_INTERIX_MSVC etc. Then, to the extent that these are all the same, it seems like I did a good thing separating "target" from "configuration"? Or again, compiler is a configuration thing, runtime due to jmpbuf size is something the compiler needs to know about, and processor actually the compiler hardly cares about -- it has to know 32bit vs. 64bit, and then just to call cm3cg usually.. :) Anyway, let's retable the general issue and just, PERHAPS, discuss Interix/SFU. A target/config name is probably all, X86_INTERIX or X86_SFU, or X86_MSWINX or X86_WINPOSIX or X86_POSIX_MS or X86_POSIX_NT X86_NTPOSIX something.. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 24 16:42:02 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 15:42:02 +0000 Subject: [M3devel] duplicate link info for stuff that has been deleted? In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: do-cm3-std buildship == package C:\dev2\cm3.2\m3-www\http == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5. 6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSI ON_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ --- building in NT386GNU --- ignoring ../src/m3overrides Fatal Error: duplicate link info: FastLex.i3 I know I know, not a big deal, easy workaround: => do-pkg http realclean But is this something the builder is supposed to handle? I'm too lazy to read the code right now... ps: here's a hueristic: if two libraries have identical code, it might be a good candidate for libm3? :) (I'm all for kitchen sink libraries, that way I can just depend on one and not worry about it. I'm a heretic though, I know.) - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 24 16:53:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:53:16 +0100 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: <20080224165316.xibqnumt6sg0s8kk@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Jay : > >> Oh darn, inevitably that is not my final answer.. >> more like attached.. > > Jay, > > the files seem to work OK on my FreeBSD system. But the tinderbox > tests on birch and new have failed, in spite of my CVS revert; > so please don't commit anything until I have found out what is wrong. > It may take some time, because I'm expecting guests soon and won't > be able to do much until tomorrow evening. OK, I think I've found it, two different reasons for the failures. On Linux we need to use libiodbc instead of libodbc as on FreeBSD, and on new.elego.de the changes just hadn't been cvsupped. On Darwin the tests succeeded again, though, so my change had an effect. Jay, you can commit your latest cm3 versions now, and I'll try to correct the odbc stuff. We'll know if it works tomorrow morning then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 24 16:58:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 15:58:20 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: Ok, I see: http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-FreeBSD4.html#tr_m3-db-odbcIt really must be: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Path.m3.diff?r1=1.14;r2=1.15 The error is unable to open "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../odbc/FreeBSD4/.M3EXPORTS" but it should be trying to open: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../../../odbc/FreeBSD4/.M3EXPORTS" or, fixed up: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/FreeBSD4/.M3EXPORTS" My change is making it remove two instances of .. at once or something like that. I still am not reading it fully, but this must be it. Overrides are often/usually "built down" from ROOT, but in this case they are "built up". Anyway I'm off to debug: == package C:\dev2\cm3.2\m3-obliq\obliqrt == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++--- building in NT386GNU --- ignoring ../src/m3overrides /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB/cygdrive/C/cm3/bin/shobjcodegen: Processing ObValue.ReplObjStd"/cygdrive/C/cm3/pkg/sharedobj/src/sharedobj.tmpl", line 49: quake runtime error: exit 35584: /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB and I have guests coming soon too. :) - Jay > Date: Sun, 24 Feb 2008 16:32:05 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: Revert cm3 to version 6 days ago> > Quoting Jay :> > > Oh darn, inevitably that is not my final answer..> > more like attached..> > Jay,> > the files seem to work OK on my FreeBSD system. But the tinderbox> tests on birch and new have failed, in spite of my CVS revert;> so please don't commit anything until I have found out what is wrong.> It may take some time, because I'm expecting guests soon and won't> be able to do much until tomorrow evening.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000> >> >> > Olaf can you try the attached? Thanks, - Jay> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Feb 24 22:54:34 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 Feb 2008 13:54:34 -0800 Subject: [M3devel] paths.. In-Reply-To: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Olaf, you're right: People who use Cygwin are used to dealing with all kinds of oddities. I am here reproducing "README.CYGWIN" from the top level of my M3 project (note the stuff after "IMPORTANT SECTION FOLLOWS"). In my opinion (and I think of everyone else who appears to use NT386GNU and also post to this mailing list) the point of Cygwin is to work as a crutch for Unix people who really, really don't want to use Windows, but are forced for some (probably economic) reason to do so... We want as much Unix and as little Windows as possible, and we're willing to jump through all sorts of hoops to get our way.... Mika # # $Id: README.CYGWIN,v 1.3 2007/07/28 23:43:50 mika Exp $ # ===== Basic instructions ===== If you are just building, not maintaining, just export CYGWIN=1 before compiling. If you are not building as user "mika", you will have to make some changes to Make.defs (please look at that file). ===== From-Scratch Installation ===== Installing this system on Cygwin can be a little tricky. So far, it's only been tested with the old PM3 distribution from Klagenfurt (?). This PM3 comes on 44 "floppies" and is installed in accordance with the instructions (in German) located at http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html Having installed the PM3 distribution, building small, self-contained Modula-3 programs should be no problem. However, it is different with this software distribution. During the build process, tools are built that are used later on in the same build process. For various reasons, m3 "overrides" don't seem to work right on Cygwin/PM3-Klagenfurt, so we build a "distribution" system and m3ship everything. ===== IMPORTANT SECTION FOLLOWS ===== The main thing that has to be done to simplify the work of the build system is to make sure that DOS and Cygwin directory paths match AS MUCH AS POSSIBLE. This is difficult, because by default, Cygwin has a different view of the "root" of the filesystem from the standard DOS view. Running under Cygwin, the Klagenfurt system unfortunately sometimes takes the DOS view and sometimes takes the Cygwin view. The situation is further complicated by the fact that Windows doesn't have proper symbolic links. The saving grace is that Cygwin DOES have proper symbolic links. The solution is therefore to make the directory structure that is desired under DOS and then link to it from within the Cygwin hierarchy. Therefore: Move the users' home directories to C:\home and make the links as follows: Cygwin link DOS equivalent /home -> /cygdrive/c/home C:\cygwin\home -> C:\home etc. The filenames are still occasionally polluted by DOS things like backslashes and drive letters. The scripts in cygwinhacks should take care of most of the remaining problems of this sort. I am not sure this system can be made to work if your system disk is called anything other than C:. Best not to try. (end of README.CYGWIN) Olaf Wagner writes: >Jay, > >I'm not really happy with NT386GNU using PathnameWin32.m3. >In my opininion it should just use the POSIX code, whatever problems >people will have with their installation roots. (These can be avoided >by using the /cygdrive/... equivalents.) >Why don't we just assume that by deafult CM3 is installed in >/usr/local/cm3 as for all other targets (except NT386, of course)? > >One thing that immediately comes to mind is that all paths output >by CM3 programs will contain \ instead of / then and thus be >unusable for simple copy-and-paste, as \ is the escape character >in all POSIX command line tools. So this seems kind of incompatible >to me. > >Olaf > >Quoting Jay : > >> I could be wrong about many things here: >> >> Cygwin fopen and I presume open accepts all of: >> c:\foo, c:/foo, /foo, \foo >> >> /foo and \foo probably have a different meaning between Cygwin and Win32. >> In Win32, /foo and \foo are, well, \foo, on the current drive. >> In Cygwin, /foo is probably /foo at the Cygwin root. >> I'd kind of like to be wrong here, about \foo having different >> meanings between them, since it a common form for me. >> >> Cygwin does not accept c:foo. >> In Win32 c:foo is foo in the current working directory of the C: drive. >> I don't think c:foo is used often, but it does have a meaning. >> >> Now, as well, cm3 has its own Path module, M3Path, but I realized >> tonight it also uses libm3's Pathname module a fair amount. In >> particular, I was having errors "shipping". >> >> This throws a big monkey wrench into where I was going. >> So now, after a bunch of going back and forth on various uncommited >> changes, I have now switched (and commited) NT386GNU to use >> PathnameWin32.m3. To some extent, this strikes at the core of "what >> is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". >> However, remember that Cygwin does appear to accept Win32 paths. >> So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that >> Win32 accepts /foo, is it Posix?) As well, this target still uses >> cygwin1.dll for its all its odd behaviors. It still uses >> open/read/write (again, remember that msvcrt.dll DOES expose these >> SAME functions..I still contend that Win32 is close enough to Posix >> to satisfy almost everyone..and then X Windows can be dealt with >> separately maybe, or Trestle/Win32 fixed). >> >> I have some more testing to do but I think this switch will fly, and >> various other options can go away. >> And I can undo the small amount I had commited. >> I think I'll just send my m3path.m3 diff around and then delete it. >> >> I ended up with a set based approach where host and target have a >> set of dir separaters, volume separaters, and separators (union of >> previous two). These are TINY sets, containing a maximum of three >> characters each, and '/' is always a member of two of them. So a set >> is kind of overkill. But it works out pretty ok. >> >> - Jay >> _________________________________________________________________ >> Need to know the score, the latest news, or you need your >> Hotmail??-get your "fix". >> http://www.msnmobilefix.com/Default.aspx > > > >-- >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Sun Feb 24 20:59:30 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 24 Feb 2008 13:59:30 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> Message-ID: <47C1CCA2.8060503@wichita.edu> Ahh, I get it. This will be much simpler than I thought. Darko wrote: > What I meant to say below is that unpacked structures are aligned > according to the normal rules under Darwin. The problem is that the > packed alignment rules without the change are too restrictive. > > On 24/02/2008, at 4:31 AM, Rodney M. Bates wrote: > >> I guess I misunderstood. I had the idea from the quoted text below >> that MAC OS X needed a mixture >> of lazy and strict alignment. If every platform uses the same >> alignment rules for all types of all >> programs on the platform, then the alignment rule property can just >> be made an additional field of >> the RTPacking.T. >> >> This is much easier to do without compatibility problems, because >> this value is encoded in bits >> in a 32-bit word in pickle headers, with unused bits that are now >> ignored. The alignment strategy >> could just be in another bit. >> >> >> From a post on 2-11: >> --------------------------------------------------------------------------------------------------------- >> >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All other >> structures should use normal alignment to be compatible with C and >> Unix interfaces. The alignment change was implemented to be >> supported only in packed structures as a natural and intuitive way >> to "force" alignment. You could view it as a bug fix to overly >> restrictive alignment rules in packed structures. >> >> >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >> >> > It sounds like all that Mac OS X needs is for _all_ types in an entire >> > program to use the liberal packing rules. Have I understood >> correctly? >> > I would have no grief over that. >> --------------------------------------------------------------------------------------------------------- >> >> >> Darko wrote: >> >>> The alignment rules are particular to a platform, not a type (at >>> least after we get rid of the pragma), so is there no field where >>> we can encode some information about the platform in the pickle >>> header or something? Where is endian stored? >> >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 mika at async.caltech.edu Sun Feb 24 23:24:30 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 Feb 2008 14:24:30 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> Message-ID: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Surely the SPIN people had to do that? I've wanted it a few times, too. Mika =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Once, there was a talk about (original?) CM3 making checked runtime >errors behave like exceptions? >-- >Dragi??a Duri?? From jayk123 at hotmail.com Mon Feb 25 09:13:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:13:50 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: Here is an unnecessarily complete explanation: The problem was Given "a../..", M3Path.FixPath wasn't doing anything. I wanted to fix that. It would collapse "a/.." or ".a/.." or "a./.." correctly, but not "a../.." I know people will disagree as to what is "correct" due to symlinks, but this was/is the behavior. Given input like "../.." it should also leave that alone, because "there is nowhere for it to go". In fixing "a../.." to collapse to nothing or ".", I also broke leaving "../.." alone. I thought the check for "is the element prior to ".." also ".."?" wasn't needed, since they get removed, left to right, and the scan is restarted for every change, but they aren't removed if "there is nowhere to go", so the check is valid. But the check wasn't right. It didn't check for a ".." element, it checked for an element ending in "..". NOW it should be treating them both correctly, as well as not indexing out of bounds for other input as it was doing. I added a check that the previous element is of length 2, and "ends" "..". Yes, I realize that elements ending in ".." but not equal to ".." are rare and not particularly interesting. Windows even has trouble with them: C:\>mkdir a.. C:\>dir a* 02/25/2008 12:11 AM a Huh? C:\>mkdir \\?\c:\a.. C:\>dir a* 02/25/2008 12:11 AM a 02/25/2008 12:12 AM a.. C:\>rmdir a.. C:\>dir a* 02/25/2008 12:12 AM a.. Huh? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.comDate: Sun, 24 Feb 2008 15:58:20 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] Revert cm3 to version 6 days ago Ok, I see:http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-FreeBSD4.html#tr_m3-db-odbcIt really must be:http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Path.m3.diff?r1=1.14;r2=1.15 The error is unable to open "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../odbc/FreeBSD4/.M3EXPORTS" but it should be trying to open: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../../../odbc/FreeBSD4/.M3EXPORTS" or, fixed up: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/FreeBSD4/.M3EXPORTS" My change is making it remove two instances of .. at once or something like that.I still am not reading it fully, but this must be it. Overrides are often/usually "built down" from ROOT, but in this case they are "built up". Anyway I'm off to debug:== package C:\dev2\cm3.2\m3-obliq\obliqrt == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++--- building in NT386GNU ---ignoring ../src/m3overrides/cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB/cygdrive/C/cm3/bin/shobjcodegen: Processing ObValue.ReplObjStd"/cygdrive/C/cm3/pkg/sharedobj/src/sharedobj.tmpl", line 49: quake runtime error: exit 35584: /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB and I have guests coming soon too. :) - Jay > Date: Sun, 24 Feb 2008 16:32:05 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: Revert cm3 to version 6 days ago> > Quoting Jay :> > > Oh darn, inevitably that is not my final answer..> > more like attached..> > Jay,> > the files seem to work OK on my FreeBSD system. But the tinderbox> tests on birch and new have failed, in spite of my CVS revert;> so please don't commit anything until I have found out what is wrong.> It may take some time, because I'm expecting guests soon and won't> be able to do much until tomorrow evening.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000> >> >> > Olaf can you try the attached? Thanks, - Jay> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:31:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:31:47 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: It is easier than today I think, and might be made even easier. Unix doesn't have to be as hard as possible, though I guess I'm a heretic on this point too. Unix seems to be all about making things much harder than necessary. I am using a workaround for at least some scenarios. In particular I have some NTFS junctions and some Cygwin symlinks. Though the symlinks are just for shorter paths and I think unnecessary. Cygwin symlinks: /c => /cygdrive/c /dev2 => /c/dev2 (and then recurse) /cm3 => /c/cm3 (and then recurse) NTFS junctions: (I use sysinternals.com's junction.exe to set these up) \cygdrive\c => c:\ \c\cm3 => c:\cm3 (aka /c/cm3, on current drive, and win32 accepts forward slashes, voila) \c\dev2 => c:\dev2 (aka /c/cdev2, likewise) You could also setup in-memory symlinks I believe with subst and/or DefineDosDevice. This way I can cross build either from either. Just bringing up CM3/Cygwin and "staying there", I don't think requires this. Nor does starting from the distribution I provided,I think. I guess I should test that, and if I am wrong, document these as "officially" needed. (X86_CYGWIN?, X86_MINGWIN? X86_INTERIX, X86_POSIX_CYGWIN, X86_WIN32_MINGWIN, X86_POSIX_INTERIX?) I also do some path conversion in the Python wrappers. I would strongly consider the following: in cm3.exe, set the quake variables INSTALLROOT and ROOT very much like how the Python/sh/Quake code does. Something like: If the environment variable CM3_ROOT is set, set ROOT to it. If the environment variable CM3_INSTALL is set, set INSTALLROOT to it. I wouldn't mind while at it coming up with longer more clear names -- CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. Convert INSTALLROOT and ROOT to what is native to cm3.exe. Possibly write the variables back out to the environment, though that should be not necessary. If M3CONFIG is set in the environment, convert it to what is native cm3.exe. For all this work, only accept full paths. That removes ambiguity since /foo is a valid Win32 path. If the environment variables are not set, CM3_INSTALL can be gleaned from cm3.exe's own path. On Windows this is from GetModuleHandleW(NULL). On other platforms, I guess argv[0]? /Possibly/ by searching $PATH for cm3.exe, but that fails if I run cm3.exe by full path and it isn't in $PATH, so no. CM3_ROOT /maybe/ should not be sniffed out. You could do it by checking for CVS directory in current working directory and then going up until CVS/Repository has no slashes, something like that. Yes, I know that is specific to using CVS, doesn't work if you are sitting elsewhere, doesn't work when another source control system is used, etc. But it is very much correct today and fast enough and when it works, is correct (ok..sitting in another CVS tree?) and makes things just a little easier to use. Automation is the name of the game, right? Otherwise we'd all be programming in assembly or ones and zeros. - Jay > To: wagner at elegosoft.com> Date: Sun, 24 Feb 2008 13:54:34 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Olaf, you're right:> > People who use Cygwin are used to dealing with all kinds of oddities.> > I am here reproducing "README.CYGWIN" from the top level of my M3> project (note the stuff after "IMPORTANT SECTION FOLLOWS"). In my > opinion (and I think of everyone else who appears to use NT386GNU and> also post to this mailing list) the point of Cygwin is to work as a> crutch for Unix people who really, really don't want to use Windows,> but are forced for some (probably economic) reason to do so... We> want as much Unix and as little Windows as possible, and we're willing> to jump through all sorts of hoops to get our way....> > Mika> > > #> # $Id: README.CYGWIN,v 1.3 2007/07/28 23:43:50 mika Exp $> #> > ===== Basic instructions =====> > If you are just building, not maintaining, just > > export CYGWIN=1> > before compiling.> > If you are not building as user "mika", you will have to make some> changes to Make.defs (please look at that file).> > ===== From-Scratch Installation =====> > Installing this system on Cygwin can be a little tricky. So far, it's> only been tested with the old PM3 distribution from Klagenfurt (?).> This PM3 comes on 44 "floppies" and is installed in accordance with the> instructions (in German) located at> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > Having installed the PM3 distribution, building small, self-contained > Modula-3 programs should be no problem.> > However, it is different with this software distribution. During the> build process, tools are built that are used later on in the same build> process. For various reasons, m3 "overrides" don't seem to work right on> Cygwin/PM3-Klagenfurt, so we build a "distribution" system and m3ship> everything.> > ===== IMPORTANT SECTION FOLLOWS =====> > The main thing that has to be done to simplify the work of the build> system is to make sure that DOS and Cygwin directory paths match AS> MUCH AS POSSIBLE. This is difficult, because by default, Cygwin has> a different view of the "root" of the filesystem from the standard> DOS view. Running under Cygwin, the Klagenfurt system unfortunately> sometimes takes the DOS view and sometimes takes the Cygwin view.> The situation is further complicated by the fact that Windows doesn't> have proper symbolic links.> > The saving grace is that Cygwin DOES have proper symbolic links.> The solution is therefore to make the directory structure that is desired> under DOS and then link to it from within the Cygwin hierarchy.> > Therefore:> > Move the users' home directories to > > C:\home> > and make the links as follows:> > Cygwin link DOS equivalent> /home -> /cygdrive/c/home C:\cygwin\home -> C:\home> > etc.> > The filenames are still occasionally polluted by DOS things like> backslashes and drive letters. The scripts in cygwinhacks should take> care of most of the remaining problems of this sort.> > I am not sure this system can be made to work if your system disk> is called anything other than C:. Best not to try.> > (end of README.CYGWIN)> > Olaf Wagner writes:> >Jay,> >> >I'm not really happy with NT386GNU using PathnameWin32.m3.> >In my opininion it should just use the POSIX code, whatever problems> >people will have with their installation roots. (These can be avoided> >by using the /cygdrive/... equivalents.)> >Why don't we just assume that by deafult CM3 is installed in> >/usr/local/cm3 as for all other targets (except NT386, of course)?> >> >One thing that immediately comes to mind is that all paths output> >by CM3 programs will contain \ instead of / then and thus be> >unusable for simple copy-and-paste, as \ is the escape character> >in all POSIX command line tools. So this seems kind of incompatible> >to me.> >> >Olaf> >> >Quoting Jay :> >> >> I could be wrong about many things here:> >>> >> Cygwin fopen and I presume open accepts all of:> >> c:\foo, c:/foo, /foo, \foo> >>> >> /foo and \foo probably have a different meaning between Cygwin and Win32.> >> In Win32, /foo and \foo are, well, \foo, on the current drive.> >> In Cygwin, /foo is probably /foo at the Cygwin root.> >> I'd kind of like to be wrong here, about \foo having different > >> meanings between them, since it a common form for me.> >>> >> Cygwin does not accept c:foo.> >> In Win32 c:foo is foo in the current working directory of the C: drive.> >> I don't think c:foo is used often, but it does have a meaning.> >>> >> Now, as well, cm3 has its own Path module, M3Path, but I realized > >> tonight it also uses libm3's Pathname module a fair amount. In > >> particular, I was having errors "shipping".> >>> >> This throws a big monkey wrench into where I was going.> >> So now, after a bunch of going back and forth on various uncommited > >> changes, I have now switched (and commited) NT386GNU to use > >> PathnameWin32.m3. To some extent, this strikes at the core of "what > >> is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > >> However, remember that Cygwin does appear to accept Win32 paths. > >> So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > >> Win32 accepts /foo, is it Posix?) As well, this target still uses > >> cygwin1.dll for its all its odd behaviors. It still uses > >> open/read/write (again, remember that msvcrt.dll DOES expose these > >> SAME functions..I still contend that Win32 is close enough to Posix > >> to satisfy almost everyone..and then X Windows can be dealt with > >> separately maybe, or Trestle/Win32 fixed).> >>> >> I have some more testing to do but I think this switch will fly, and > >> various other options can go away.> >> And I can undo the small amount I had commited.> >> I think I'll just send my m3path.m3 diff around and then delete it.> >>> >> I ended up with a set based approach where host and target have a > >> set of dir separaters, volume separaters, and separators (union of > >> previous two). These are TINY sets, containing a maximum of three > >> characters each, and '/' is always a member of two of them. So a set > >> is kind of overkill. But it works out pretty ok.> >>> >> - Jay> >> _________________________________________________________________> >> Need to know the score, the latest news, or you need your > >> Hotmail??-get your "fix".> >> http://www.msnmobilefix.com/Default.aspx> >> >> >> >-- > >Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany> >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin> >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:32:56 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:32:56 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: It is easier than THAT today, I meant, otherwise ambiguous and I could have been saying your way is easier than mine. I'm lazy and so I try to make things easy for myself. :) - Jay From: jayk123 at hotmail.comTo: mika at async.caltech.edu; wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] paths..Date: Mon, 25 Feb 2008 08:31:47 +0000 It is easier than today I think, and might be made even easier.Unix doesn't have to be as hard as possible, though I guess I'm a heretic on this point too.Unix seems to be all about making things much harder than necessary. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:33:52 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:33:52 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: got truncated again... Here is an unnecessarily complete explanation: The problem was Given "a../..", M3Path.FixPath wasn't doing anything. I wanted to fix that. It would collapse "a/.." or ".a/.." or "a./.." correctly, but not "a../.." I know people will disagree as to what is "correct" due to symlinks, but this was/is the behavior. Given input like "../.." it should also leave that alone, because "there is nowhere for it to go". In fixing "a../.." to collapse to nothing or ".", I also broke leaving "../.." alone. I thought the check for "is the element prior to ".." also ".."?" wasn't needed, since they get removed, left to right, and the scan is restarted for every change, but they aren't removed if "there is nowhere to go", so the check is valid. But the check wasn't right. It didn't check for a ".." element, it checked for an element ending in "..". NOW it should be treating them both correctly, as well as not indexing out of bounds for other input as it was doing.I added a check that the previous element is of length 2, and "ends" "..". Yes, I realize that elements ending in ".." but not equal to ".." are rare and not particularly interesting.Windows even has trouble with them: C:\>mkdir a.. C:\>dir a* 02/25/2008 12:11 AM a Huh? C:\>mkdir \\?\c:\a.. C:\>dir a* 02/25/2008 12:11 AM a 02/25/2008 12:12 AM a.. C:\>rmdir a.. C:\>dir a* 02/25/2008 12:12 AM a.. Huh? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:40:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:40:10 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: > process. For various reasons, m3 "overrides" don't seem to work right on ps: I believe overrides work in CM3/NT386GNU today. At least I didn't do anything to workaround them not working. buildship and upgrade and make-dist all seem to work and I believe the second two depend on overrides. I have seen overrides vary between using SL and /, but either should always work now. PathnameWin32.m3 and M3Path.m3 always recognize / as a directory separator, which is correct, unless you prefix the paths with \\? in which case it is arguably incorrect. Please do try the distribution I put out there. Or try building it yourself from current source. Thanks. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:50:08 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:50:08 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: This sounds very much how Windows has been but finally changed. It used to be in C++ you could do: try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ else catch (...) { printf("caught exception\n"); } now you can't. Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. The most common one is an "access violation". There's also "stack overflow". And others. They can be raised by code via RaiseException though. There is a similar syntax for catching them -- __try / __except. Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"? In particular, Win32 structured exceptions fall into two or three classes: Someone called RaiseException. These are orderly and reasonable to catch, but rare. (Even if C++ exceptions are implemented via RaiseException.) Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some data somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" corrupt. I suggest a NULL deref might be the third class, but not clear. If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the case, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops. What about integer overflow? I wonder. :) - Jay > To: dragisha at m3w.org> Date: Sun, 24 Feb 2008 14:24:30 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well...> > Surely the SPIN people had to do that?> > I've wanted it a few times, too.> > Mika> > =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:> >Once, there was a talk about (original?) CM3 making checked runtime> >errors behave like exceptions?> >-- > >Dragi??a Duri?? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 15:47:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 14:47:44 +0000 Subject: [M3devel] shipping with overrides? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: I understand that when you build with overrides, you can't ship. "package was built with overrides, not shipping." My question is the opposite. Why can some packages apparently ship despite being built with overrides?For example m3middle? Something obvious? Probably. Something to be debugged? - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 16:12:36 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 15:12:36 +0000 Subject: [M3devel] M3Path.FixPath rewrite? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: M3Path.FixPath had some flaws, mainly: it uses a fixed size array to store the locations of path separators in the presence of too many separators, it'd ignore stuff every occurence of . or .. causes it to restart its work (after removing it) I have written a new version with these aspects fixed. Anyone care to try it out? diff and m3path.m3 attached. There's a small test harness built in, disabled. You can feed strings through the old and new and compare. They don't always match. I think my results are "more correct". Thanks, - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: M3Path.m3 URL: From jayk123 at hotmail.com Mon Feb 25 16:38:38 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 15:38:38 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: I know this area has been brewing under the surface a while. I'll bring it up. :) Here is some apparently typical code: PROCEDURE Escape (nm: TEXT): TEXT = VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; BEGIN IF (nm = NIL) THEN RETURN NIL; END; len := Text.Length (nm); IF (len + len <= NUMBER (buf)) THEN RETURN DoEscape (nm, len, buf); ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + len)^); END; END Escape; PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF CHAR): TEXT = VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; BEGIN Text.SetChars (buf, nm); FOR i := 0 TO len-1 DO IF (buf[i] = BackSlash) THEN INC (n_escapes); END; END; IF (n_escapes = 0) THEN RETURN nm; END; src := len - 1; dest := src + n_escapes; WHILE (src > 0) DO c := buf[src]; DEC (src); buf[dest] := c; DEC (dest); IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); END; END; RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); END DoEscape;Look at how inefficient this is. For a long string it makes a heap allocation, even if in the end it makes no changes to the string. For any length string it copies it out to an array. Then if there are any changes, it copies it again, probably into heap, likely the input immediately becoming garbage. Heap allocation may be fast, but building up garbage and causing more work for the garbage collector I assume is bad. And if the string had no backslashes, it's all a big waste. I assume texts are read only? I know lots of systems have read only strings. There are pluses and minus to them. They can be single-instanced. Some systems with read only strings have another type, such as "StringBuilder" or "StringBuffer". So -- I don't have a specific question, but maybe a mutable string "class" aka "type" is needed?Not necessarily in the language but in m3core or libm3? Maybe it's already there? I just spent a few hours diddling with arrays of chars. Unfortunately they are not resizable. It was not entirely satisfactory. Besides the array I had to pass around a length and a start. Wrapping this up in one record TYPE MutableString= ... might be a good idea. For more efficient read only access, would it be reasonable for the runtime to materialize on-demand 8 bit and 16 bit representations of a string if a user calls some new thing like Text.GetDirectA (t: TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF WIDECHAR? Throw an exception if the string cannot be represented with 8 bit characters? Or use utf8? Besides, I know I'm a big predictable whiner but I like how this works in Windows.. It may not have been as seamless, but it works and it really doesn't tend to break or slow down existing code. roughly: "foo" is an 8 bit string of type char* (or const char* or possibly const char[4]) L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) "L" for "long" aka "wide" Functions must be written to specifically use one or the other. In C++ you can templatize. There is std::string and std::wstring that are template instantiations. Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc. And really there's no point in 8 bit strings. If you have a blob, that's an array of bytes or something, not characters. It works. Utf8 is another seemingly popular route but I think it's a hack. I think mostly people don't touch their code and say, voila, it's utf8, and they only really support the same old English or possibly 8 bit characters (some European characters). Granted, to some extent, this does work, as long as you don't do anything with the string but strlen, strcpy, and some others and pass it to code that does treat it correctly. Still, variably sized encodings seem like a bad idea here, and 16 bits per character seem affordable enough. And yes, I know that Unicode is actually know 20 bits per character and some characters take two wchar_ts but I try to ignore that... And I know there is a lot of existing code, but sometimes there is a need for progress too... Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:13:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:13:05 +0000 Subject: [M3devel] test.. In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: looks like m3commit is broken again... _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:15:34 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:15:34 +0000 Subject: [M3devel] thread.fork getting nil on nt386gnu? In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: any obvious ideas? I'll have to pause for a bit again..Jay at jay-win1 /cygdrive/c/dev2/cm3.2/m3-ui/juno-2/juno-app/NT386GNU/Juno.exe ****** runtime error:*** Thread client error: NIL apply method passed to Thread.Fork!*** file "ThreadWin32.m3", line 578*** 14837 [sig] Juno 3908 c:\dev2\cm3.2\m3-ui\juno-2\juno-app\NT386GNU\Juno.exe: *** fatal error - called with threadlist_ix -1Hangup - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:22:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:22:47 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> References: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Message-ID: This was causing NT386GNU shobjgen to crash so I went ahead and wrapped up all the globals in functions. m3commit isn't working. I'm building linuxlibc6 on birch now. Solaris is probably affected. Darwin and I think FreeBSD are not affected. And some inactive platforms -- HPUX, Irix, Linux aout 1.x. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] utime.i3 and imported dataDate: Wed, 13 Feb 2008 11:01:51 +0000 > From: hosking at cs.purdue.edu> > Aren't these all superseded by gettimeofday?> > I say just not support the global variable access.> > Utime.i3 on other platforms does not have these globals.Could be. I don't know this stuff.. They are currently used though. I didn't happen here by chance..I'll maybe poke around.I guess this is a time to send diffs and get sign off on all platforms.OR fork the file backwards to DateLinuxOld.m3, DateBsdOld.m3, move everyone to it, then fix DateLinux/Bsd to have no data and as people test their platform move forward? And the last guy turn off the lights?(This is a philosophical and real question. The first approach is slower but moves cleanly all at once from good to good. The second approach allows a gradual migration that starts right away and leaves a cluttered history in its wake but arrives at the same place, possibly but not necessarily sooner.) Anyway, my workaround I think is working.. - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 03:19:16 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 25 Feb 2008 18:19:16 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Mon, 25 Feb 2008 08:50:08 GMT." Message-ID: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Jay, Sometimes I wonder if you have never read the Green Book!!! The very first section of the Modula-3 definition, Section 2.1 of the Green Book, talks about the distinction between "checked runtime errors" and "unchecked runtime errors" and ends with the sentence "Unchecked runtime errors can occur only in unsafe modules." If I may make one of those philosophical diversions that so often lead to Language Wars (but in this case isn't intended to), you mentioned something a while back along the lines of (I am not quoting you verbatim) "every line of code is part of an application's interface, because it can cause...a change in memory usage or expose a previously unknown race condition".. The whole point of Modula-3 is that Modula-3 is part of a family of tools, a way of thinking, even, under which this isn't true. If you use the garbage collector alluded to by Knuth, timing changes in your program CANNOT cause it to run out of memory. If you use the Extended Static Checker (coded by some of the same people who did Modula-3), timing changes to your program CANNOT expose unknown race conditions because there ARE no race conditions in your program! And if you use Modula-3 the way you're supposed to---that is, use the safe features almost exclusively and use UNSAFE code so sparingly that it is obviously (i.e., provably) correct, you will have NO unchecked runtime errors! Now it is true that we live in an imperfect world, and that neither any mortal nor any product of any mortal is perfect, but the WHOLE POINT of Modula-3 is to be a stepping-stone to this type of perfection!!!! All of its users are longing to one day be programming in the Elysian Fields where there are no race conditions, heap overflows due to lazy garbage collectors, nor any unchecked runtime errors. Will we ever get there? I don't know. But for me at least, one of the reasons I use Modula-3 is because it tries, and I can see how one might fill in the gaps and get it all the way. I know of no other programming environment that comes to within several orders of magnitude of Modula-3's performance and satisfies the same properties. Integer overflow: the Green Book says that the language catches it. Implementations generally don't, as far as I know. The specification is really only fifty pages long... Mika Jay wrote: >This sounds very much how Windows has been but finally changed. > > It used to be in C++ you could do: > > try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ > else catch (...) { printf("caught exception\n"); } > > now you can't. > Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". > "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. > The most common one is an "access violation". There's also "stack overflow". And others. > They can be raised by code via RaiseException though. > > There is a similar syntax for catching them -- __try / __except. > > Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"? > In particular, Win32 structured exceptions fall into two or three classes: > Someone called RaiseException. These are orderly and reasonable to catch, but rare. > (Even if C++ exceptions are implemented via RaiseException.) > Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) > This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some dat >a somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" >corrupt. I suggest a NULL deref might be the third class, but not clear. > >If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the cas >e, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops. > >What about integer overflow? I wonder. :) > > - Jay From jayk123 at hotmail.com Tue Feb 26 01:36:49 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 00:36:49 +0000 Subject: [M3devel] test? Message-ID: Just testing..mailing lists seem down again.. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 04:01:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 03:01:50 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> References: Your message of "Mon, 25 Feb 2008 08:50:08 GMT." <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Message-ID: Mika, I do need to reread that book, yes. Most of my reading of it was years ago. Yes the odds of me confusing checked and unchecked errors are real. I think I might have speculated as to the way things really are, while talking mainly about how things perhaps are not. However..I still believe the implementation is the interface. I don't see how Modula-3 fixes that. > If you use the garbage collector alluded to by Knuth, timing changes> in your program CANNOT cause it to run out of memory. I didn't mean to necessarily link these things together. Let's say garbage is collected immedately upon it being created. A program still has a certain amount of non-garbage memory allocated at any one time, and that amount might grow or shrink as changes are made to the code. How about this backwards example: Let's say I have some code that does a heap allocation and handles arbitrarily large data. I find it is slow and I replace it with a fixed sized array. Boom, I break anyone using large data. Now, granted, this is a dumb, backwards example. But it is an implementation detail not revealed in the .i3 file. The .i3 file, like, the "binary" interface. If you get those to match, well, great, your stack won't be unbalanced, safe code will be safe, but nothing will necessarily be correct. > If you use the Extended Static Checker (coded by some of the same people > who did Modula-3), timing changes to your program CANNOT expose unknown Well...I'm ignorant of this particular checker. I am familiar with some of the static checking that is ot there. Only recently have I seen any static checking for race conditions. This is against and C and C++ code, mind you. Perhaps they "resisted" static analysis until recently, hard to parse and all that.. Anyway, while I am not an expert on static checking potential and practise, I have seen just an astounding number of "crazy" bugs and I don't see much hope for much automatic bug detection. Most of the "bugs" found by static checking are very basic things, like leaks or forgetting to check an error, and never something particularly high level as to what the code is actually supposed to do. I mean..I'm not sure this is a valid example or not, but let's say I have the functions Plus and Minus, and let's say I'm a terrible typist and I implement Plus with - and Minus with +. What static checking will catch that. Now, yes, I grant, any amount of manual dynamic testing will catch it. But I think the point is valid -- static checking never checks much. Generalized automatic checking never checks much. The best you can do is along the lines of m3-sys/tests -- a small "framework" for "running stuff" and "comparing the output against expected", perhaps being amitious and including "negative tests" (make sure erroneous source code fails to compile and gives a good error message). I guess, to put a positive light on things, the best we can hope for is some sort of composition of larger systems out of available parts that are already well tested and known to work fairly well. However, this is just..like..a fractal. Those available parts are built up out of yet again smaller well tested parts. And so on down the line. And no layer or part is free of bugs. Processors have bugs. Compilers have bugs. "operating systems" (which are really nothing special -- just another bunch of libraries) have bugs. "There are bugs everywhere". "More code => more bugs, even if that code is meant to find bugs, such as assertion failures" => people put in incorrect assertions, oops, they trigger, let's go and remove or loosen the assertion. I just don't see static checking making all that much headway against the tremendous variety of things programmers do wrong. "Safety" is a nice step, get the easy things, the buffer overflows, but that still leaves lots of room for error (look at how my "safe" m3path.m3 broke the tinderbox for example....) I think Modula-3 was very far ahead of its time. I think a lot of systems have caught up. I grant that most of the systems that have caught up might not catch all the way up, they are either not as safe or not as performant. Again, really, I think correctness is about far more than safety, and that implementation is interface, because safety or no safety, code can depend on nearly arbitrary characteristics of the code it uses. Ok, I'm repeating myself now, sorry. I don't think I see an argument here btw. Modula-3 is what it is. It solves some problems. It doesn't do the impossible. Have you used the NT386 system btw? One of the great things about Modula-3 is only parsing the headers once, and a resulting very fast compiler. However on non-NT386 the gcc backend all but ruins this perf. The integrated compiler is just way way way way faster than the gcc backend... you (all) should try it. Gotta go, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika at async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the Green Book!!!> > The very first section of the Modula-3 definition, Section 2.1 of> the Green Book, talks about the distinction between "checked runtime> errors" and "unchecked runtime errors" and ends with the sentence> "Unchecked runtime errors can occur only in unsafe modules."> > If I may make one of those philosophical diversions that so often> lead to Language Wars (but in this case isn't intended to), you> mentioned something a while back along the lines of (I am not quoting> you verbatim) "every line of code is part of an application's> interface, because it can cause...a change in memory usage or expose> a previously unknown race condition"..> > The whole point of Modula-3 is that Modula-3 is part of a family> of tools, a way of thinking, even, under which this isn't true.> > If you use the garbage collector alluded to by Knuth, timing changes> in your program CANNOT cause it to run out of memory.> > If you use the Extended Static Checker (coded by some of the same people> who did Modula-3), timing changes to your program CANNOT expose unknown> race conditions because there ARE no race conditions in your program!> > And if you use Modula-3 the way you're supposed to---that is, use the> safe features almost exclusively and use UNSAFE code so sparingly that> it is obviously (i.e., provably) correct, you will have NO unchecked> runtime errors!> > Now it is true that we live in an imperfect world, and that neither> any mortal nor any product of any mortal is perfect, but the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> perfection!!!! All of its users are longing to one day be programming> in the Elysian Fields where there are no race conditions, heap> overflows due to lazy garbage collectors, nor any unchecked runtime> errors. Will we ever get there? I don't know. But for me at> least, one of the reasons I use Modula-3 is because it tries, and> I can see how one might fill in the gaps and get it all the way.> I know of no other programming environment that comes to within> several orders of magnitude of Modula-3's performance and satisfies> the same properties.> > Integer overflow: the Green Book says that the language catches it.> Implementations generally don't, as far as I know.> > The specification is really only fifty pages long...> > Mika> > Jay wrote:> >This sounds very much how Windows has been but finally changed. > > > > It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ > > else catch (...) { printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". > > "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. > > The most common one is an "access violation". There's also "stack overflow". And others.> > They can be raised by code via RaiseException though.> > > > There is a similar syntax for catching them -- __try / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"?> > In particular, Win32 structured exceptions fall into two or three classes:> > Someone called RaiseException. These are orderly and reasonable to catch, but rare. > > (Even if C++ exceptions are implemented via RaiseException.) > > Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) > > This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some dat> >a somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a NULL deref might be the third class, but not clear.> > > >If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the cas> >e, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonder. :)> > > > - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 04:47:03 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 25 Feb 2008 19:47:03 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." Message-ID: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> I believe the main reason the compiler is slow on most platforms is that it sleeps for 0.1 seconds every time it spawns a process. My private version of the compiler has that sleep taken out and runs probably 20x faster (for a typical compile). Jay, I still say you are ignorant of a huge part of the history of Computer Science---in this you are joined by 99% of people who use computers, by the way. You should in fact not start with the Green Book, but with this: http://www.masswerk.at/algol60/report.htm And reflect upon these words (again, from "The Humble Programmer", Dijkstra's 1972 Turing Award lecture): The fourth project to be mentioned is ALGOL 60. While up to the present day FORTRAN programmers still tend to understand their programming language in terms of the specific implementation they are working with hence the prevalence of octal and hexadecimal dumps, while the definition of LISP is still a curious mixture of what the language means and how the mechanism works, the famous Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine effort to carry abstraction a vital step further and to define a programming language in an implementation-independent way. One could argue that in this respect its authors have been so successful that they have created serious doubts as to whether it could be implemented at all! The report gloriously demonstrated the power of the formal method BNF, now fairly known as Backus-Naur-Form, and the power of carefully phrased English, a least when used by someone as brilliant as Peter Naur. I think that it is fair to say that only very few documents as short as this have had an equally profound influence on the computing community. The ease with which in later years the names ALGOL and ALGOL-like have been used, as an unprotected trade mark, to lend some of its glory to a number of sometimes hardly related younger projects, is a somewhat shocking compliment to its standing. The strength of BNF as a defining device is responsible for what I regard as one of the weaknesses of the language: an over-elaborate and not too systematic syntax could now be crammed into the confines of very few pages. With a device as powerful as BNF, the Report on the Algorithmic Language ALGOL 60 should have been much shorter... [talk about parameter-passing in Algol 60] How large a data structure a given program can process is clearly part of its interface, like so: PROCEDURE A(VAR r : ARRAY OF INTEGER); (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) Whether that particular bit of information can be represented in a machine-readable form or not is open to question, but irrelevant. C and C++ don't get much in the way of static verification not because they have messy syntax but because they have poorly understood (sometimes, plainly undefined, I am told) semantics. And yes that is why they started with Modula-3. The readers and writers (Rd and Wr) libraries, as they came out of SRC, have been statically verified to be entirely free of deadlock and I believe also incorrect data accesses. I was at a talk that Greg Nelson gave about this at Caltech a few years ago, but I don't remember all the details---just that they found a few previously unknown bugs. This is what all those <* LL *> pragmas are all about. The ESC project continued with Java. I think the people are all at Microsoft now, but ESC is still available, I believe both for Modula-3 and Java (I think the Java version is still written in Modula-3). Btw, the example that Greg Nelson showed when he gave his demo (live on a laptop!) *did* catch a problem with + vs. - (well it was an array index that was off by 1, and it was caught statically, but it clearly depended on the checker's knowing about + vs. -). And yes you are right, of course, testing never shows much. Another Dijkstraism (from 1970): Program testing can be used to show the presence of bugs, but never to show their absence! It is clear that if you actually want to be certain your program is correct (and some people do, some of the time), you will have to invest in some sort of formal reasoning. In order for it to be tractable, you need simple languages, languages that are not defined by their implementations (because trying to understand that would be hopeless). If you can do that, you can at least divide your bugs into the categories "application bugs" and "language implementation bugs". It is *not* a feature or shortcoming of Modula-3 that its arithmetic rolls over instead of raising an exception on overflow. The language spec is clear on it: in Modula-3, overflows are to be checked runtime errors. It is a compiler shortcoming (or bug) that they aren't checked. And yes, Modula-3 was far ahead, in exactly the same way that Backus, Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson, Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960. But no, absolutely no one has caught up. The utterly vast majority of people who deal with computers still have absolutely no understanding of how to handle system complexity. I am sure that this sad state of affairs is familiar enough to every reader of this email that I don't have to multiply examples. Finally, I'm really not talking about language features.. safe vs. unsafe, avoidance of bus errors, etc. It's a question of tools of the human mind more than it is a question of compiler implementation and runtime systems---not, where do you want to go today? but, do you UNDERSTAND where you are going today? Remember that programming languages are for HUMANS, not computers. Computers couldn't care less what language you are programming in. In fact they would be "happier" if you just typed in the machine code directly! Mika Jay writes: >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Mika, I do need to reread that book, yes. Most of my reading of it was year= >s ago. >Yes the odds of me confusing checked and unchecked errors are real. I think= > I might have speculated as to the way things really are, while talking mai= >nly about how things perhaps are not. >=20 >However..I still believe the implementation is the interface. >I don't see how Modula-3 fixes that. >=20 >> If you use the garbage collector alluded to by Knuth, timing changes> in = >your program CANNOT cause it to run out of memory. >I didn't mean to necessarily link these things together. >Let's say garbage is collected immedately upon it being created. >A program still has a certain amount of non-garbage memory allocated at any= > one time, and that amount might grow or shrink as changes are made to the = >code. >=20 >How about this backwards example: Let's say I have some code that does a he= >ap allocation and handles arbitrarily large data. I find it is slow and I r= >eplace it with a fixed sized array. Boom, I break anyone using large data. = >Now, granted, this is a dumb, backwards example. But it is an implementatio= >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int= >erface. If you get those to match, well, great, your stack won't be unbalan= >ced, safe code will be safe, but nothing will necessarily be correct. >=20 > > If you use the Extended Static Checker (coded by some of the same people= > > who did Modula-3), timing changes to your program CANNOT expose unknown= >=20 >Well...I'm ignorant of this particular checker. I am familiar with some of = >the static checking that is ot there. Only recently have I seen any static = >checking for race conditions. This is against and C and C++ code, mind you.= > Perhaps they "resisted" static analysis until recently, hard to parse and = >all that.. Anyway, while I am not an expert on static checking potential an= >d practise, I have seen just an astounding number of "crazy" bugs and I don= >'t see much hope for much automatic bug detection. Most of the "bugs" found= > by static checking are very basic things, like leaks or forgetting to chec= >k an error, and never something particularly high level as to what the code= > is actually supposed to do. I mean..I'm not sure this is a valid example o= >r not, but let's say I have the functions Plus and Minus, and let's say I'm= > a terrible typist and I implement Plus with - and Minus with +. What stati= >c checking will catch that. Now, yes, I grant, any amount of manual dynamic= > testing will catch it. But I think the point is valid -- static checking n= >ever checks much. Generalized automatic checking never checks much. The bes= >t you can do is along the lines of m3-sys/tests -- a small "framework" for = >"running stuff" and "comparing the output against expected", perhaps being = >amitious and including "negative tests" (make sure erroneous source code fa= >ils to compile and gives a good error message). >=20 >I guess, to put a positive light on things, the best we can hope for is som= >e sort of composition of larger systems out of available parts that are alr= >eady well tested and known to work fairly well. However, this is just..like= >..a fractal. Those available parts are built up out of yet again smaller we= >ll tested parts. And so on down the line. And no layer or part is free of b= >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which = >are really nothing special -- just another bunch of libraries) have bugs. "= >There are bugs everywhere". "More code =3D> more bugs, even if that code is= > meant to find bugs, such as assertion failures" =3D> people put in incorre= >ct assertions, oops, they trigger, let's go and remove or loosen the assert= >ion. >=20 >I just don't see static checking making all that much headway against the t= >remendous variety of things programmers do wrong. "Safety" is a nice step, = >get the easy things, the buffer overflows, but that still leaves lots of ro= >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp= >le....) >=20 >I think Modula-3 was very far ahead of its time. I think a lot of systems h= >ave caught up. >I grant that most of the systems that have caught up might not catch all th= >e way up, they are either not as safe or not as performant. >=20 >Again, really, I think correctness is about far more than safety, and that = >implementation is interface, because safety or no safety, code can depend o= >n nearly arbitrary characteristics of the code it uses. >=20 >Ok, I'm repeating myself now, sorry. >=20 >I don't think I see an argument here btw. Modula-3 is what it is. It solves= > some problems. It doesn't do the impossible. >=20 >Have you used the NT386 system btw? One of the great things about Modula-3 = >is only parsing the headers once, and a resulting very fast compiler. Howev= >er on non-NT386 the gcc backend all but ruins this perf. The integrated com= >piler is just way way way way faster than the gcc backend... you (all) shou= >ld try it. >=20 >Gotta go, > - Jay > > > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika= >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the= > Green Book!!!> > The very first section of the Modula-3 definition, Sectio= >n 2.1 of> the Green Book, talks about the distinction between "checked runt= >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un= >checked runtime errors can occur only in unsafe modules."> > If I may make = >one of those philosophical diversions that so often> lead to Language Wars = >(but in this case isn't intended to), you> mentioned something a while back= > along the lines of (I am not quoting> you verbatim) "every line of code is= > part of an application's> interface, because it can cause...a change in me= >mory usage or expose> a previously unknown race condition"..> > The whole p= >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t= >hinking, even, under which this isn't true.> > If you use the garbage colle= >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t= >o run out of memory.> > If you use the Extended Static Checker (coded by so= >me of the same people> who did Modula-3), timing changes to your program CA= >NNOT expose unknown> race conditions because there ARE no race conditions i= >n your program!> > And if you use Modula-3 the way you're supposed to---tha= >t is, use the> safe features almost exclusively and use UNSAFE code so spar= >ingly that> it is obviously (i.e., provably) correct, you will have NO unch= >ecked> runtime errors!> > Now it is true that we live in an imperfect world= >, and that neither> any mortal nor any product of any mortal is perfect, bu= >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p= >erfection!!!! All of its users are longing to one day be programming> in th= >e Elysian Fields where there are no race conditions, heap> overflows due to= > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g= >et there? I don't know. But for me at> least, one of the reasons I use Modu= >la-3 is because it tries, and> I can see how one might fill in the gaps and= > get it all the way.> I know of no other programming environment that comes= > to within> several orders of magnitude of Modula-3's performance and satis= >fies> the same properties.> > Integer overflow: the Green Book says that th= >e language catches it.> Implementations generally don't, as far as I know.>= > > The specification is really only fifty pages long...> > Mika> > Jay wrot= >e:> >This sounds very much how Windows has been but finally changed. > > > = >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1= >); } /* access violation, reading from address 1 */ > > else catch (...) { = >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) = >catches all C++ exceptions but not these "Win32 structured exceptions". > >= > "Win32 structured exceptions" are generally "hardware exceptions" made vis= >ible to software. > > The most common one is an "access violation". There's= > also "stack overflow". And others.> > They can be raised by code via Raise= >Exception though.> > > > There is a similar syntax for catching them -- __t= >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly= >" and so more "catchable"?> > In particular, Win32 structured exceptions fa= >ll into two or three classes:> > Someone called RaiseException. These are o= >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i= >mplemented via RaiseException.) > > Someone has some corrupted data and "ac= >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more = >common case, and if you catch such an exception, you have to wonder, uh, so= >me data is corrupt..which data? What can I possily do at this point, given = >that some dat> >a somewhere is corrupt? It could be the heap. It could be t= >he stack. It could be something small that I'm not going to touch. Heck, ma= >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N= >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a= >n adequate job of noticing things as soon as they have gone bad, and not at= > an indeterminate point afterward, that sounds more viable. I suspect this = >might be the cas> >e, as long as you haven't called out to some buggy C cod= >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde= >r. :)> > > > - Jay=20 >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Mika, I do need to reread that book, yes. Most of= > my reading of it was years ago.
>Yes the odds of me confusing checked and unchecked errors are real. I think= > I might have speculated as to the way things really are, while talking mai= >nly about how things perhaps are not.
> 
>However..I still believe the implementation is the interface.
>I don't see how Modula-3 fixes that.
> 
>> If you use the garbage collector alluded to by Knuth, timing changesR>> in your program CANNOT cause it to run out of memory.

>I didn't mean to necessarily link these things together.
>Let's say garbage is collected immedately upon it being created.
>A program still has a certain amount of non-garbage memory allocated at any= > one time, and that amount might grow or shrink as changes are made to the = >code.
> 
>How about this backwards example: Let's say I have some code that does a he= >ap allocation and handles arbitrarily large data. I find it is slow and I r= >eplace it with a fixed sized array. Boom, I break anyone using large data. = >Now, granted, this is a dumb, backwards example. But it is an implementatio= >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int= >erface. If you get those to match, well, great, your stack won't be unbalan= >ced, safe code will be safe, but nothing will necessarily be correct.
> 
> > If you use the Extended Static Checker (coded by some of the sam= >e people
 > who did Modula-3), timing changes to your program C= >ANNOT expose unknown

>Well...I'm ignorant of this particular checker. I am familiar with some of = >the static checking that is ot there. Only recently have I seen any static = >checking for race conditions. This is against and C and C++ code, mind you.= > Perhaps they "resisted" static analysis until recently, hard to parse and = >all that.. Anyway, while I am not an expert on static checking potential an= >d practise, I have seen just an astounding number of "crazy" bugs and I don= >'t see much hope for much automatic bug detection. Most of the "bugs" found= > by static checking are very basic things, like leaks or forgetting to chec= >k an error, and never something particularly high level as to what the code= > is actually supposed to do. I mean..I'm not sure this is a valid example o= >r not, but let's say I have the functions Plus and Minus, and let's say I'm= > a terrible typist and I implement Plus with - and Minus with +. What stati= >c checking will catch that. Now, yes, I grant, any amount of manual dynamic= > testing will catch it. But I think the point is valid -- static checking n= >ever checks much. Generalized automatic checking never checks much. The bes= >t you can do is along the lines of m3-sys/tests -- a small "framework" for = >"running stuff" and "comparing the output against expected", perhaps being = >amitious and including "negative tests" (make sure erroneous source code fa= >ils to compile and gives a good error message).
> 
>I guess, to put a positive light on things, the best we can hope for is som= >e sort of composition of larger systems out of available parts that are alr= >eady well tested and known to work fairly well. However, this is just..like= >..a fractal. Those available parts are built up out of yet again smaller we= >ll tested parts. And so on down the line. And no layer or part is free of b= >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which = >are really nothing special -- just another bunch of libraries) have bugs. "= >There are bugs everywhere". "More code =3D> more bugs, even if that code= > is meant to find bugs, such as assertion failures" =3D> people put in i= >ncorrect assertions, oops, they trigger, let's go and remove or loosen the = >assertion.
> 
>I just don't see static checking making all that much headway against the t= >remendous variety of things programmers do wrong. "Safety" is a nice step, = >get the easy things, the buffer overflows, but that still leaves lots of ro= >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp= >le....)
> 
>I think Modula-3 was very far ahead of its time. I think a lot of systems h= >ave caught up.
>I grant that most of the systems that have caught up might not catch all th= >e way up, they are either not as safe or not as performant.
> 
>Again, really, I think correctness is about far more than safety, and that = >implementation is interface, because safety or no safety, code can depend o= >n nearly arbitrary characteristics of the code it uses.
> 
>Ok, I'm repeating myself now, sorry.
> 
>I don't think I see an argument here btw. Modula-3 is what it is. It solves= > some problems. It doesn't do the impossible.
> 
>Have you used the NT386 system btw? One of the great things about Modula-3 = >is only parsing the headers once, and a resulting very fast compiler. Howev= >er on non-NT386 the gcc backend all but ruins this perf. The integrated com= >piler is just way way way way faster than the gcc backend... you (all) shou= >ld try it.
> 
>Gotta go,
> - Jay


> >
>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18= >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
= >>
> Sometimes I wonder if you have never read the Green Book!!!R>>
> The very first section of the Modula-3 definition, Section = >2.1 of
> the Green Book, talks about the distinction between "checked= > runtime
> errors" and "unchecked runtime errors" and ends with the s= >entence
> "Unchecked runtime errors can occur only in unsafe modules.= >"
>
> If I may make one of those philosophical diversions that= > so often
> lead to Language Wars (but in this case isn't intended to= >), you
> mentioned something a while back along the lines of (I am no= >t quoting
> you verbatim) "every line of code is part of an applicati= >on's
> interface, because it can cause...a change in memory usage or = >expose
> a previously unknown race condition"..
>
> The = >whole point of Modula-3 is that Modula-3 is part of a family
> of too= >ls, a way of thinking, even, under which this isn't true.
>
> = >If you use the garbage collector alluded to by Knuth, timing changes
>= >; in your program CANNOT cause it to run out of memory.
>
> If= > you use the Extended Static Checker (coded by some of the same people
&= >gt; who did Modula-3), timing changes to your program CANNOT expose unknown= >
> race conditions because there ARE no race conditions in your progr= >am!
>
> And if you use Modula-3 the way you're supposed to---t= >hat is, use the
> safe features almost exclusively and use UNSAFE cod= >e so sparingly that
> it is obviously (i.e., provably) correct, you w= >ill have NO unchecked
> runtime errors!
>
> Now it is tr= >ue that we live in an imperfect world, and that neither
> any mortal = >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo= >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All= > of its users are longing to one day be programming
> in the Elysian = >Fields where there are no race conditions, heap
> overflows due to la= >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev= >er get there? I don't know. But for me at
> least, one of the reasons= > I use Modula-3 is because it tries, and
> I can see how one might fi= >ll in the gaps and get it all the way.
> I know of no other programmi= >ng environment that comes to within
> several orders of magnitude of = >Modula-3's performance and satisfies
> the same properties.
> <= >BR>> Integer overflow: the Green Book says that the language catches it.= >
> Implementations generally don't, as far as I know.
>
>= >; The specification is really only fifty pages long...
>
> Mik= >a
>
> Jay wrote:
> >This sounds very much how Windows= > has been but finally changed.
> >
> > It used to be in= > C++ you could do:
> >
> > try { printf("%s\n", (char*)= > 1); } /* access violation, reading from address 1 */
> > else ca= >tch (...) { printf("caught exception\n"); }
> >
> > now= > you can't.
> > Now catch (...) catches all C++ exceptions but no= >t these "Win32 structured exceptions".
> > "Win32 structured exce= >ptions" are generally "hardware exceptions" made visible to software.
&= >gt; > The most common one is an "access violation". There's also "stack = >overflow". And others.
> > They can be raised by code via RaiseExc= >eption though.
> >
> > There is a similar syntax for cat= >ching them -- __try / __except.
> >
> > Now, maybe Modu= >la-3 runtime errors are "more orderly" and so more "catchable"?
> >= >; In particular, Win32 structured exceptions fall into two or three classes= >:
> > Someone called RaiseException. These are orderly and reasona= >ble to catch, but rare.
> > (Even if C++ exceptions are implement= >ed via RaiseException.)
> > Someone has some corrupted data and "= >access violated" (aka: some sort of signal/tap on Unix)
> > This = >is the more common case, and if you catch such an exception, you have to wo= >nder, uh, some data is corrupt..which data? What can I possily do at this p= >oint, given that some dat
> >a somewhere is corrupt? It could be t= >he heap. It could be the stack. It could be something small that I'm not go= >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >> >corrupt. I suggest a NULL deref might be the third class, but not= > clear.
> >
> >If Modula-3 does an adequate job of notic= >ing things as soon as they have gone bad, and not at an indeterminate point= > afterward, that sounds more viable. I suspect this might be the cas
>= >; >e, as long as you haven't called out to some buggy C code or some uns= >afe Modula-3, oops.
> >
> >What about integer overflow? = >I wonder. :)
> >
> > - Jay


Climb to = >the top of the charts!=A0Play the word scramble challenge with star power. = >textlink_jan' target=3D'_new'>Play now! >= > >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- From jayk123 at hotmail.com Tue Feb 26 08:07:49 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 07:07:49 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> References: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> Message-ID: Mika you underestimate me somewhat but maybe not entirely. I have never used Algol.I should do a bit more research. BNF to me is, you know, like a grammar, LALR, LL, yacc, PCCTS, whatever. It is very useful step, a very good way to state what it states.But as I understand only describes syntax and not semantics. I could say is:English: subject verb [and verb]*Jay sits. okJay stands. okJay gallops. Syntactically correct but not semantically. Jay is not a horse.It is not type correct. Programming languages catch these errors usually,you don't need "extended static checking".Or you could be type correct but still wrong:Jay dies and lives. Something has to know that living cannot occur after dying.How do I state that? I think C++ is actually underappreciated here.Stroupstrup alludes to a style of programming where all side affectsare via constructor calls. I believe this is "very functional".I haven't yet seen anyone elaborate on this.Add type safety to that."Jay = Jay->die()" would return a subtype of human_t that does not have the live() method.Type checking can possibly do a lot of this.(sorry this is so morbid, I had to think of operations that could not go in acertain sequqence. I guess a better one would be Jay learns to program and Jay is born.) Being syntactically correct is a necessary first step, and thencomes type safety, and then comes actually doing what is intended. Maybe BNF has more features than I assume. I have been exposed to multiple opposing views, such as: as you say -- programs are for people first, computers second The SICP book was very interesting.. and the contrary -- performance, performance, performance Too much abstraction and you lose touch with the machine that doesultimately have to run your creation and if it is runs it too slowly,well, that does matter. (Humans are not going to run your program after all; they are much too slow.) I have a lot of real world practical experience.Not as much maybe as I should but a lot. > How large a data structure a given program can process is clearly > part of its interface, like so: > PROCEDURE A(VAR r : ARRAY OF INTEGER); > (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) Your example proves my point. The "specification" is a comment written in English.Nothing will check it. It might change. Worse, the level of detail in a commentis totally up to the programmer. If the comment was missing, what would theinterface be? That the function does nothing? I contend that there is no language that can state the complete specification.The language of the implementation comes close, however it then rests on what is below it,and so on down the line. Science has apparently figured out enough that "and so on downthe line" doesn't go all that far. We know the computer is digital, 0s and 1s, we don't haveto talk about how the transistors work to spec a function. I will look into the sleep.Can it not be a, um, a wait? You know, wait specifically for the process to exit?At the same time as reading its stdout and stderr?Actually I have some experience here...It turns out, on Windows, that it is very easy to deadlock writing code like this.There about three simple patterns, one that deadlocks, two that don't. pseudo code: 1)process = CreateProcess();if process not done read some from stdout echo it to my stdout read some from stderr echo it to my stderr This can deadlock.IF the child process ONLY writes to one of stdout or stderr, I think no deadlock.But if it writes to both, can deadlock. 2)process = CreateProcesscreate another thread (or have one already created waiting for work to do)optionally create another thread for symmetry of implementation, but inefficienthave one thread read/echo stderr, the other read/echo stdoutThis won't deadlock. 3)create the process such that stdout and stderr are the samethen just read that one pipe/handle/file/whatever, on one thread I guess, I have to check, I think on Windows you do like WaitForMultipleObjects(2, [pipe and process]).I have to check if the pipe is signaled by having data available. And then I have to look into what Posix offers here.Maybe have NT386GNU not use Posix here, however..having tried this for "serial", having done it with Thread,the various implementation pieces are not always so easily mixed and matched.For example PosixFile wants PosixScheduler, which is not usually "with" ThreadWin32, but I put in a dummy one. Having both FileWin32 and FilePosix available, with one being the revealer of File.T would be good.I think this is a simple restructuring of the code. Knowing the machine model and how your code ends up executing on the machine is not at all a bad thing.Being careful with how large the abstraction layers you build is not a bad thing.Making a compromise between human and computer is not a bad thing.I long ago gave up writting in assembly, after all.However I am constantly viewing assembly, partly by dumb virtue of how my debugger works, butalso partly because there are bugs everywhere and everything you hide from me is an opportunityfor you to hide the bug I am looking for. Every abstraction you build is something that is going to have bugs in it that I'm going to have to debug. The less abstraction, the thinner the layers, the less debugging will be needed. But yet you do absolutely need abstraction. There is this term -- "leaky abstraction".Most abstractions leak underlying details, there it is useful to understand as much of the stack as possible. Yes, I understand, it is important to know what is an implementation detail and what is an interface/behavioralguarantee. They are often blurred. One of the things good about Modula-3 is its "portability". The fact that I can do roughly the same things already on NT386, PPC_DARWIN, PPC_LINUX "keeps my honest".I can fairly readily check my work on three kind of different systems. The counterpoint here however is that at the C level and above, all machines are converging ontwo and only two models -- Windows and Posix.Portability is becoming like English. Or English and French.Rather than come up with some very very broad commonality that you believe will be implementableon forseeable architectures, you merely have to fit only two common cases.Or heck, if Cygwin flies, only one common case.(Btw, AMD64_MINGWIN should be fairly easy to implement today, AMD64_CYGWIN not so much.There are already AMD64 MinGWin distributes. Cygwin is loaded with assembly cod and the FAQ/docsare not optimistic about AMD64. So Cygwin isn't clearly a way forward.The integrated backend of course needs work and should be viable.) Yes I know LL is about static checking of locking, though I don't know how to read/write the pragmas.I also noticed the large or lm3 or whatnot files.I should look into what they can state and check. I relatively recently amassed a fairly large collection of compilers in order to "test portability".Man it is a bit sad. CFront based C++ compilers are awful. Only one return statement per functionor something. Maybe this experiment went overboard and there's a smaller number of interestingmodern tools.. Most of the stuff that is left "undefined" in C is very reasonable to leave undefined.For example, signed integer encoding is not specified.Things like going out of bounds on arrays is probably not specified.The reason is obvious -- because it is expensive to check.I have heard of code accidentally depending on array bounds overflow.Two local variables, one could overflow into the other, accidentally doubling the capacity of the program! > in this you are joined by 99% of people who use computers Equating a PROGRAMMER with 99% of computer USERS is very insulting.Really.The family/relative tech support I do..."click the whatever." "Right click or left click?"I have had that question so many times. Good thing three button mice are not prevalent. :)(and please don't insult whoever asked me that question..) The rude thing to wonder here is something about practicality vs. theory....The Modula-3 is actually squarely in the practical camp.What with having the compiler and garbage collector implemented it, for starters. I have used Scheme btw, and I was very enamored of it.Then I started debugging some of it by stepping through STk.Man every other instruction was a type check. Despite that 99% of the type checksall succeeded, or had even already succeeded against that data.It's a great programming model, but perhaps? too difficult to implement efficiently?I don't know. One hole in my experience is working with or implementing systems that infer types,except as a user of C++ templates, which does involve a significant amount of type inference.But it's not e.g. SML or a high end efficient compilation Scheme/Lisp. Meanwhile, the mailing lists are still down. Later, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s ago.> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> If you use the garbage collector alluded to by Knuth, timing changes> in => >your program CANNOT cause it to run out of memory.> >I didn't mean to necessarily link these things together.> >Let's say garbage is collected immedately upon it being created.> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > If you use the Extended Static Checker (coded by some of the same people=> > > who did Modula-3), timing changes to your program CANNOT expose unknown=> >=20> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.> >=20> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >Gotta go,> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked runtime errors can occur only in unsafe modules."> > If I may make => >one of those philosophical diversions that so often> lead to Language Wars => >(but in this case isn't intended to), you> mentioned something a while back=> > along the lines of (I am not quoting> you verbatim) "every line of code is=> > part of an application's> interface, because it can cause...a change in me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=> >, and that neither> any mortal nor any product of any mortal is perfect, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-3 is because it tries, and> I can see how one might fill in the gaps and=> > get it all the way.> I know of no other programming environment that comes=> > to within> several orders of magnitude of Modula-3's performance and satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >This sounds very much how Windows has been but finally changed. > > > => >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=> >); } /* access violation, reading from address 1 */ > > else catch (...) { => >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) => >catches all C++ exceptions but not these "Win32 structured exceptions". > >=> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more => >common case, and if you catch such an exception, you have to wonder, uh, so=> >me data is corrupt..which data? What can I possily do at this point, given => >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n adequate job of noticing things as soon as they have gone bad, and not at=> > an indeterminate point afterward, that sounds more viable. I suspect this => >might be the cas> >e, as long as you haven't called out to some buggy C cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.
> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.
> > 
> >However..I still believe the implementation is the interface.
> >I don't see how Modula-3 fixes that.
> > 
> >> If you use the garbage collector alluded to by Knuth, timing changes >R>> in your program CANNOT cause it to run out of memory.

> >I didn't mean to necessarily link these things together.
> >Let's say garbage is collected immedately upon it being created.
> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.
> > 
> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.
> > 
> > > If you use the Extended Static Checker (coded by some of the sam=> >e people
 > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown

> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).
> > 
> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.
> > 
> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)
> > 
> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.
> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.
> > 
> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.
> > 
> >Ok, I'm repeating myself now, sorry.
> > 
> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.
> > 
> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.
> > 
> >Gotta go,
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
=> >>
> Sometimes I wonder if you have never read the Green Book!!! >R>>
> The very first section of the Modula-3 definition, Section => >2.1 of
> the Green Book, talks about the distinction between "checked=> > runtime
> errors" and "unchecked runtime errors" and ends with the s=> >entence
> "Unchecked runtime errors can occur only in unsafe modules.=> >"
>
> If I may make one of those philosophical diversions that=> > so often
> lead to Language Wars (but in this case isn't intended to=> >), you
> mentioned something a while back along the lines of (I am no=> >t quoting
> you verbatim) "every line of code is part of an applicati=> >on's
> interface, because it can cause...a change in memory usage or => >expose
> a previously unknown race condition"..
>
> The => >whole point of Modula-3 is that Modula-3 is part of a family
> of too=> >ls, a way of thinking, even, under which this isn't true.
>
> => >If you use the garbage collector alluded to by Knuth, timing changes
>=> >; in your program CANNOT cause it to run out of memory.
>
> If=> > you use the Extended Static Checker (coded by some of the same people
&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> >
> race conditions because there ARE no race conditions in your progr=> >am!
>
> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the
> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that
> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked
> runtime errors!
>
> Now it is tr=> >ue that we live in an imperfect world, and that neither
> any mortal => >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All=> > of its users are longing to one day be programming
> in the Elysian => >Fields where there are no race conditions, heap
> overflows due to la=> >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev=> >er get there? I don't know. But for me at
> least, one of the reasons=> > I use Modula-3 is because it tries, and
> I can see how one might fi=> >ll in the gaps and get it all the way.
> I know of no other programmi=> >ng environment that comes to within
> several orders of magnitude of => >Modula-3's performance and satisfies
> the same properties.
> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> >
> Implementations generally don't, as far as I know.
>
>=> >; The specification is really only fifty pages long...
>
> Mik=> >a
>
> Jay wrote:
> >This sounds very much how Windows=> > has been but finally changed.
> >
> > It used to be in=> > C++ you could do:
> >
> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */
> > else ca=> >tch (...) { printf("caught exception\n"); }
> >
> > now=> > you can't.
> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions".
> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software.
&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.
> > They can be raised by code via RaiseExc=> >eption though.
> >
> > There is a similar syntax for cat=> >ching them -- __try / __except.
> >
> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?
> >=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:
> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare.
> > (Even if C++ exceptions are implement=> >ed via RaiseException.)
> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix)
> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat
> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.
> >
> >If Modula-3 does an adequate job of notic=> >ing things as soon as they have gone bad, and not at an indeterminate point=> > afterward, that sounds more viable. I suspect this might be the cas
>=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.
> >
> >What about integer overflow? => >I wonder. :)
> >
> > - Jay


Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => > >textlink_jan' target=3D'_new'>Play now!> >=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Feb 26 11:00:54 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 26 Feb 2008 11:00:54 +0100 Subject: [M3devel] CM3 package dependicies Message-ID: <1204020054.7354.2.camel@hias.m3w.org> I am trying to figure out systematic way to map dependicies of packages so I can make nice hierarchy for RPM building... It's not too hard to map it out from m3makefiles, but it will be much better if someone already solved it :). Is there such a map already out there? TIA, dd -- Dragi?a Duri? From wagner at elegosoft.com Tue Feb 26 11:36:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:36:07 +0100 Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Quoting Jay : > M3Path.FixPath had some flaws, mainly: it uses a fixed size array > to store the locations of path separators in the presence of too > many separators, it'd ignore stuff every occurence of . or .. > causes it to restart its work (after removing it) > I have written a new version with these aspects fixed. > Anyone care to try it out? > diff and m3path.m3 attached. > There's a small test harness built in, disabled. > You can feed strings through the old and new and compare. > They don't always match. I think my results are "more correct". Sorry, it will take some time till I can test these. Why don't you add the test to the package test framework in m3-sys/cm3/tests/src/TestM3Path or similar? Provide a list of input paths and expected output in files; this will make things easier to understand for others. If you add the tests first and wait one day until checking in your change we can see the impacts in the package test results in our tinderbox. Generally I think we should start adding tests for everything we change; there's so much breakage that can be avoided this 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 wagner at elegosoft.com Tue Feb 26 11:45:51 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:45:51 +0100 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <20080226114551.2b0icwj0g4ocw4wg@mail.elegosoft.com> Quoting Jay : > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > I assume texts are read only? Yes. > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed?Not necessarily in the language but in > m3core or libm3? > Maybe it's already there? For string construction you can use TextWr.T. I wouldn't object to a mutable string type as an extension though; but it won't be too easy to design. Unless you are willing to suggest some interface, we should just add this issue to the long-term TODO list. I'd rather prefer getting everything more stable again. The more tests I try to add to the regression, the more problems show up :-/ Olaf > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > _________________________________________________________________ > Helping your favorite cause is as easy as instant messaging. You IM, we give. > http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 26 11:55:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:55:09 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: <1204020054.7354.2.camel@hias.m3w.org> References: <1204020054.7354.2.camel@hias.m3w.org> Message-ID: <20080226115509.oqmdrn0ruo00gwog@mail.elegosoft.com> Quoting Dragi?a Duri? : > I am trying to figure out systematic way to map dependicies of packages > so I can make nice hierarchy for RPM building... It's not too hard to > map it out from m3makefiles, but it will be much better if someone > already solved it :). Is there such a map already out there? Elego ComPact had programs to extract package dependencies (m3dep) and build dependency graphs for projects. I had already started to add some of the old stuff to my local CM3 workspace, but it will take some time until it's ready to commit. I'm currently stuck in libm3 tests automation. I was thinking of adding a simplified and M3-specific version of the ComPact project manager as alternative or replacement to the various build scripts. That's still some work though, and I haven't got much 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 hendrik at topoi.pooq.com Tue Feb 26 17:33:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 26 Feb 2008 11:33:12 -0500 Subject: [M3devel] Do I remember well... In-Reply-To: References: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Message-ID: <20080226163312.GA14499@topoi.pooq.com> On Tue, Feb 26, 2008 at 03:01:50AM +0000, Jay wrote: > > I just don't see static checking making all that much headway against the tremendous variety of things programmers do wrong. "Safety" is a nice step, get the easy things, the buffer overflows, but that still leaves lots of room for error (look at how my "safe" m3path.m3 broke the tinderbox for example....) Static checking is a huge help. Every error caught by a static check is an error clearly and effectively reported to you. You don't have to spend time analysing the run-time behaviour of your program to figure out what's wrong. Granted, there are still lots of things to do wrong. Run-time checks (with garbage collection) help further by enforcing the abstract-machine model of the language. This means that you never have wild pointers or out-of-bounds subscripts in a data structure in one part of a program wreaking havoc on an unrelated part. And those bugs can take *days* to track down. No. These things don't solve all problems. They don't ensure program correctness. But they sure make it easy to track down most problems. -- hendrik From jayk123 at hotmail.com Tue Feb 26 18:39:06 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 17:39:06 +0000 Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite? In-Reply-To: <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: I can't argue adding tests per change is a good idea. I was on a team where at least every bug fix had to come with an automatic regression test, if not every initial change, though of course, you could do the second. My problem historically has been lack of a framework -- how to write tests, how to run them, how to verify them, how to debug them. m3-sys\m3tests appears to be a plenty adequate framework for locally authoring, running, verifying, debugging, plus the tinderbox for ongoing status (not that, as far as I know, the tinderbox is debuggable in-situ, but still, this is plenty). I submitted the change but disabled. It's now a very small diff to enable What is the story on exposing internals to testing though? I see several options, all with pluses and minus: Expose more stuff in the .i3 file. Possibly with names like "Internal" or "Test" in them. Not great but easy and works. Invoke test code from module initialization having checked Params for M3testfoo or such. Not great but easy and often works. Adds unnecessary code to the runtime. Getting better I think: Add FooInternal.i3 or FooTest.i3. Export it from Foo.m3. I guess even to the pkg store? Call it from the text executable (also want to call FooTest.m3). This still exposes internals to callers, but at least with a clear distinction of what is internal or not. I guess another name here is FooFriend.i3. For that matter, split off the testable code into FooTest.m3. Same thing? Somehow "preprocess" the code to extract parts you want to call from test code. I'm not keen on designing a preprocessor. Aha, combine the last few? Split up Foo.m3 into FooTest.m3 and Foo.m3. Both exports only parts of Foo.i3, which is unchanged. Add FooTest.i3 that is empty? "Preprocessing" becomes a) copy an .m3 file b) replace an .i3 file (FooTest.i3)? There, I designed preprocessing, as file copying. There's also the matter of chosing the test cases that matter and not just a bunch of random strings that are obviously handled correctly but I guess just err toward throwing in more strings. - Jay > Date: Tue, 26 Feb 2008 11:36:07 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite?> > Quoting Jay :> > > M3Path.FixPath had some flaws, mainly: it uses a fixed size array > > to store the locations of path separators in the presence of too > > many separators, it'd ignore stuff every occurence of . or .. > > causes it to restart its work (after removing it)> > I have written a new version with these aspects fixed.> > Anyone care to try it out?> > diff and m3path.m3 attached.> > There's a small test harness built in, disabled.> > You can feed strings through the old and new and compare.> > They don't always match. I think my results are "more correct".> > Sorry, it will take some time till I can test these.> > Why don't you add the test to the package test framework> in m3-sys/cm3/tests/src/TestM3Path or similar?> Provide a list of input paths and expected output in files;> this will make things easier to understand for others.> If you add the tests first and wait one day until checking in> your change we can see the impacts in the package test results> in our tinderbox.> > Generally I think we should start adding tests for everything we> change; there's so much breakage that can be avoided this 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> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 18:47:31 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 17:47:31 +0000 Subject: [M3devel] cross "compiling" In-Reply-To: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> References: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> Message-ID: This may be obvious to everyone and so inadequate as to be useless, but I just had a minor idea and proved it correct. Even if you don't have a backend, C compiler, linker, etc, you can still compile the Modula-3 code for any target from any target. If you just put return 0 in the config file for backend, compile_c, link, make_lib, assembly, you can at least run the front/middle ends. For example I just compiled m3core and libm3 for Solaris. That would have caught my DatePosix.m3 error, though that sort of change was maybe one that just can't be commited without an available machine. (I'm still not sure how to do these things. You can only change what you have, or send diffs around and wait for the all clear, or you can make a best effort and hope..) Obviously it only affords a certain minimal amount of checking. But it is perhaps something. IN FACT...maybe it is enough testing that the tinderboxes should do it, for all platforms deemed "supported"? I don't think you can ship, but you can buildlocal. (I built libm3, depends on m3core). I'll push this a bit further. IF this is deemed useful, maybe a compiler switch? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Feb 26 19:34:28 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 26 Feb 2008 12:34:28 -0600 Subject: [M3devel] Is the climate right for a new promotion? Message-ID: <47C45BB4.40009@wichita.edu> I have been thinking lately that the climate might be right for a new attempt to promote Modula 3. I see two major trends and a small one that suggest this. Fist, probably nearly once week on the average, I see new articles that say that software developers are not prepared to utilize the now- proliferating multi-core processors. This actually greatly surprises me, because I had lots of exposure, decades ago, to all the concurrent programming stuff--threads, synchronization, scheduling, etc. But apparently, most programmers have been doing strictly sequential programming, and I have to admit, I myself only use concurrent programming techniques a minority of the time. In Modula-3, we have a language that already has better support than most, and certainly better than all the popular languages. Moreover, the implementation is out if front too, with Tony's recent thread and GC work for multi-processors. There are also a few articles out there that say, in effect, it is hopeless to implement threads and synchronization correctly as library code on top of existing C/C++. Second, the expansion of the internet and its vulnerability to automated attacks from anywhere in the world has greatly upped the ante on correctness of software. Before, it was enough if a program handled all the realistic cases that a reasonable user would present it with. Now, the whole theoretical space of inputs has to be handled with at least some level of correctness to avoid vulnerabilities. 1000-byte passwords are the standard example. All this means the limits of testing as a means of finding the bugs are a far greater obstacle than they once were. This makes the time right for another push toward static languages, which were somewhat of a popular flop the first time. Third, and perhaps rather more narrow, the developers of safety- critical software are reexamining the value of testing in the light of various close-calls, for example in airplanes. They are starting to look again at static methods. We have a language which, though little-known, is already designed and implemented and has a lot of convincing history. It has a lot of things that can be promoted. Aside from good thread support and the best safety properties around, it is much simpler than almost anything, yet more powerful than almost anything. A serious push would probably need the support of some large company or organization. But I think the climate is better than it has been in decades, and the technical arguments are very strong. -- ------------------------------------------------------------- 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 Tue Feb 26 19:19:53 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:19:53 +0000 Subject: [M3devel] cross "compiling" In-Reply-To: References: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> Message-ID: e.g. I can get this far in scripts/python/do-cm3-all.py: --- building in SOLgnu --- <== SOLgnu /cygdrive/C/dev2/cm3.2/m3-tools/m3bundle/SOLgnu/m3bundle -name B -F/cygdrive/c/DOCUME~1/Jay/LOCALS~1/Temp/qkunable to open file for reading: ../SOLgnu/B.i3: errno=2unable to open file for reading: ../SOLgnu/B.m3: errno=2 and yes I understand the problem and I think you can trivially override it by using the "correct" host m3bundle instead of the "just built" one. (might have had to make a change to skip tapi) (and I should be able to run X86_SOLARIS in a virtual machine...) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 17:47:31 +0000Subject: [M3devel] cross "compiling" This may be obvious to everyone and so inadequate as to be useless, but I just had a minor idea and proved it correct. Even if you don't have a backend, C compiler, linker, etc, you can still compile the Modula-3 code for any target from any target. If you just put return 0 in the config file for backend, compile_c, link, make_lib, assembly, you can at least run the front/middle ends. For example I just compiled m3core and libm3 for Solaris. That would have caught my DatePosix.m3 error, though that sort of change was maybe one that just can't be commited without an available machine. (I'm still not sure how to do these things. You can only change what you have, or send diffs around and wait for the all clear, or you can make a best effort and hope..) Obviously it only affords a certain minimal amount of checking.But it is perhaps something. IN FACT...maybe it is enough testing that the tinderboxes should do it, for all platforms deemed "supported"?I don't think you can ship, but you can buildlocal. (I built libm3, depends on m3core). I'll push this a bit further. IF this is deemed useful, maybe a compiler switch? - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 19:29:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 13:29:28 -0500 Subject: [M3devel] thread.fork getting nil on nt386gnu? In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: <6346DE25-6495-49D0-A990-F48B989218AC@cs.purdue.edu> Looks like a corrupted/uninitialized type (method table contains a NIL pointer...). 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 Feb 25, 2008, at 1:15 PM, Jay wrote: > any obvious ideas? I'll have to pause for a bit again.. > > Jay at jay-win1 /cygdrive/c/dev2/cm3.2/m3-ui/juno-2/juno-app/NT386GNU/ > Juno.exe > > *** > *** runtime error: > *** Thread client error: NIL apply method passed to Thread.Fork! > *** file "ThreadWin32.m3", line 578 > *** > 14837 [sig] Juno 3908 c:\dev2\cm3.2\m3-ui\juno-2\juno-app\NT386GNU > \Juno.exe: * > ** fatal error - called with threadlist_ix -1 > Hangup > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 19:35:33 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:35:33 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> References: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> Message-ID: Hey I accidentally mostly confirmed this. I changed the backend to just "touch" and it too is slow. Now, granted, vfork in Cygwin is the same as fork, and does a big memory copy, so it could be that running anything in Cygwin is slow. But I could compare to other platforms..or just try removing it. Removing this is easy, at least for PTHREADS, right? And "user threads", can, at worst, do the sleep in their specific code? I think it might be good to run cm3cg and maybe as only once per directory besides, with all the files at once, or at least a few at time, or with a response file. Thanks, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s ago.> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> If you use the garbage collector alluded to by Knuth, timing changes> in => >your program CANNOT cause it to run out of memory.> >I didn't mean to necessarily link these things together.> >Let's say garbage is collected immedately upon it being created.> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > If you use the Extended Static Checker (coded by some of the same people=> > > who did Modula-3), timing changes to your program CANNOT expose unknown=> >=20> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.> >=20> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >Gotta go,> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked runtime errors can occur only in unsafe modules."> > If I may make => >one of those philosophical diversions that so often> lead to Language Wars => >(but in this case isn't intended to), you> mentioned something a while back=> > along the lines of (I am not quoting> you verbatim) "every line of code is=> > part of an application's> interface, because it can cause...a change in me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=> >, and that neither> any mortal nor any product of any mortal is perfect, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-3 is because it tries, and> I can see how one might fill in the gaps and=> > get it all the way.> I know of no other programming environment that comes=> > to within> several orders of magnitude of Modula-3's performance and satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >This sounds very much how Windows has been but finally changed. > > > => >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=> >); } /* access violation, reading from address 1 */ > > else catch (...) { => >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) => >catches all C++ exceptions but not these "Win32 structured exceptions". > >=> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more => >common case, and if you catch such an exception, you have to wonder, uh, so=> >me data is corrupt..which data? What can I possily do at this point, given => >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n adequate job of noticing things as soon as they have gone bad, and not at=> > an indeterminate point afterward, that sounds more viable. I suspect this => >might be the cas> >e, as long as you haven't called out to some buggy C cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.
> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.
> > 
> >However..I still believe the implementation is the interface.
> >I don't see how Modula-3 fixes that.
> > 
> >> If you use the garbage collector alluded to by Knuth, timing changes >R>> in your program CANNOT cause it to run out of memory.

> >I didn't mean to necessarily link these things together.
> >Let's say garbage is collected immedately upon it being created.
> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.
> > 
> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.
> > 
> > > If you use the Extended Static Checker (coded by some of the sam=> >e people
 > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown

> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).
> > 
> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.
> > 
> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)
> > 
> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.
> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.
> > 
> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.
> > 
> >Ok, I'm repeating myself now, sorry.
> > 
> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.
> > 
> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.
> > 
> >Gotta go,
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
=> >>
> Sometimes I wonder if you have never read the Green Book!!! >R>>
> The very first section of the Modula-3 definition, Section => >2.1 of
> the Green Book, talks about the distinction between "checked=> > runtime
> errors" and "unchecked runtime errors" and ends with the s=> >entence
> "Unchecked runtime errors can occur only in unsafe modules.=> >"
>
> If I may make one of those philosophical diversions that=> > so often
> lead to Language Wars (but in this case isn't intended to=> >), you
> mentioned something a while back along the lines of (I am no=> >t quoting
> you verbatim) "every line of code is part of an applicati=> >on's
> interface, because it can cause...a change in memory usage or => >expose
> a previously unknown race condition"..
>
> The => >whole point of Modula-3 is that Modula-3 is part of a family
> of too=> >ls, a way of thinking, even, under which this isn't true.
>
> => >If you use the garbage collector alluded to by Knuth, timing changes
>=> >; in your program CANNOT cause it to run out of memory.
>
> If=> > you use the Extended Static Checker (coded by some of the same people
&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> >
> race conditions because there ARE no race conditions in your progr=> >am!
>
> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the
> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that
> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked
> runtime errors!
>
> Now it is tr=> >ue that we live in an imperfect world, and that neither
> any mortal => >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All=> > of its users are longing to one day be programming
> in the Elysian => >Fields where there are no race conditions, heap
> overflows due to la=> >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev=> >er get there? I don't know. But for me at
> least, one of the reasons=> > I use Modula-3 is because it tries, and
> I can see how one might fi=> >ll in the gaps and get it all the way.
> I know of no other programmi=> >ng environment that comes to within
> several orders of magnitude of => >Modula-3's performance and satisfies
> the same properties.
> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> >
> Implementations generally don't, as far as I know.
>
>=> >; The specification is really only fifty pages long...
>
> Mik=> >a
>
> Jay wrote:
> >This sounds very much how Windows=> > has been but finally changed.
> >
> > It used to be in=> > C++ you could do:
> >
> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */
> > else ca=> >tch (...) { printf("caught exception\n"); }
> >
> > now=> > you can't.
> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions".
> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software.
&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.
> > They can be raised by code via RaiseExc=> >eption though.
> >
> > There is a similar syntax for cat=> >ching them -- __try / __except.
> >
> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?
> >=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:
> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare.
> > (Even if C++ exceptions are implement=> >ed via RaiseException.)
> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix)
> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat
> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.
> >
> >If Modula-3 does an adequate job of notic=> >ing things as soon as they have gone bad, and not at an indeterminate point=> > afterward, that sounds more viable. I suspect this might be the cas
>=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.
> >
> >What about integer overflow? => >I wonder. :)
> >
> > - Jay


Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => > >textlink_jan' target=3D'_new'>Play now!> >=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 19:53:58 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:53:58 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types. specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199*** Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 20:22:57 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 26 Feb 2008 11:22:57 -0800 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: Your message of "Tue, 26 Feb 2008 11:45:51 +0100." <20080226114551.2b0icwj0g4ocw4wg@mail.elegosoft.com> Message-ID: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Olaf Wagner writes: >Quoting Jay : > >> I know this area has been brewing under the surface a while. >> I'll bring it up. :) >> >> I assume texts are read only? > >Yes. > >> I know lots of systems have read only strings. >> There are pluses and minus to them. They can be single-instanced. >> Some systems with read only strings have another type, such as >> "StringBuilder" or "StringBuffer". >> So -- I don't have a specific question, but maybe a mutable string >> "class" aka "type" is needed?Not necessarily in the language but in >> m3core or libm3? >> Maybe it's already there? CharSeq.T? From jayk123 at hotmail.com Tue Feb 26 20:53:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 19:53:24 +0000 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: I haven't tested this but it looks very suspicious.. When targeting 64 bit targets, the compiler thinks [-1 .. 1] is empty. When compiling things like "compare" functions. I didn't debug it but just looked at the code. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.4 diff -r1.4 TInt.i3 26c26 < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; --- > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff}}; another fix might be: > MOne = Int{1, IBytes{16_ff}}; IBytes used to be 16 bit integers but now is 8 bit integers. PM3 has: Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; which seems adequate for what is likely going on in these parts. I believe ".." fills with zeros, not the previous value. Also, is this objectionable? RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v retrieving revision 1.2 diff -r1.2 TextLiteral.i3 15c15 < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; --- > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - 32; *) Maybe. The 32 bit compiler doesn't like such large types (that follow from the use of this). Maybe preferable to allow 32 bit hosted compiler to allow 64 bit sized types? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 18:53:58 +0000Subject: [M3devel] tangential 64 bit... alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 20:57:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 19:57:20 +0000 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Hm, I don't think that fixes it actually. I'll have to dig in later, if highlighting the problem doesn't make it obvious to others.. What was there didn't look right for 32 bits even, but probably is for some reason.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 19:53:24 +0000Subject: [M3devel] 64 bit fixes? I haven't tested this but it looks very suspicious.. When targeting 64 bit targets, the compiler thinks [-1 .. 1] is empty. When compiling things like "compare" functions. I didn't debug it but just looked at the code. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.4 diff -r1.4 TInt.i3 26c26 < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; --- > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff}}; another fix might be: > MOne = Int{1, IBytes{16_ff}}; IBytes used to be 16 bit integers but now is 8 bit integers. PM3 has: Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; which seems adequate for what is likely going on in these parts. I believe ".." fills with zeros, not the previous value. Also, is this objectionable? RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v retrieving revision 1.2 diff -r1.2 TextLiteral.i3 15c15 < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; --- > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - 32; *) Maybe. The 32 bit compiler doesn't like such large types (that follow from the use of this). Maybe preferable to allow 32 bit hosted compiler to allow 64 bit sized types? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 18:53:58 +0000Subject: [M3devel] tangential 64 bit... alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 21:14:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 15:14:18 -0500 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64- bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: > alpha/osf doesn't work because basictypes/ctypes has a problem with > the 32bit or 64bit types. > specifically "unsigned long" is "empty" for some reason and many > errors cascade from that. > > if you change: > unsigned_int = [16_0 .. 16_ffffffff]; > to > unsigned_int = [16_0 .. 16_fffffffe]; > > you get: > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/TWord.m3", line 199 > *** > > Presumably fixing this first problem is the first step in any "real" > 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem > should just be fixed as a matter of course. > > I know this is the least of anyone's concerns.. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 21:16:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 15:16:47 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: ARRAY OF CHAR/WIDECHAR? These are available in the various Text implementations. For exampe, Text8.T.contents. One can freely mutate these at leisure and the higher-level text will appear to change! On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > Olaf Wagner writes: >> Quoting Jay : >> >>> I know this area has been brewing under the surface a while. >>> I'll bring it up. :) >>> >>> I assume texts are read only? >> >> Yes. >> >>> I know lots of systems have read only strings. >>> There are pluses and minus to them. They can be single-instanced. >>> Some systems with read only strings have another type, such as >>> "StringBuilder" or "StringBuffer". >>> So -- I don't have a specific question, but maybe a mutable string >>> "class" aka "type" is needed?Not necessarily in the language but in >>> m3core or libm3? >>> Maybe it's already there? > > CharSeq.T? From jayk123 at hotmail.com Tue Feb 26 21:34:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:34:51 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Tony..are you sure..I'm not sure what I said is true. It seems clear that the host integer size is well abstracted while interpreting target numbers. I am more certain that [-1 .. 1] is empty, and this is likely a problem in TInt.Subtract.. PROCEDURE Add (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); carry := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO carry := a.x[i] + b.x[i] + carry; r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign # b_sign) OR (a_sign = r_sign); END Add; PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); borrow := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO borrow := a.x[i] - b.x[i] - borrow; r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign = b_sign) OR (a_sign = r_sign); END Subtract; Is it not adequate to treat carry and borrow as one it, zero or non-zero? Thinking in decimal about addition -- 9 + 9 = 18. You can never overflow to 20, 30, 40, etc. For substraction 0 - 9 = -9, never -10 or lower. However "1" is a full decimal digit, not a bit. In this case, the digits are bytes. Aha, so maybe the problem is the "and"? Let's check pm3 and decm3 3.6 again.. No, pm3 has the and too.. hm. I have to refresh some of my bit twiddling algorithms.. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 15:14:18 -0500 Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64-bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 21:35:56 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:35:56 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: Is that legal or is that subverting things? It depends on the context? Can the pointers be to read only memory in the code? - Jay > From: hosking at cs.purdue.edu> To: mika at async.caltech.edu> Date: Tue, 26 Feb 2008 15:16:47 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays?> > ARRAY OF CHAR/WIDECHAR?> > These are available in the various Text implementations. For exampe, > Text8.T.contents. One can freely mutate these at leisure and the > higher-level text will appear to change!> > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote:> > > Olaf Wagner writes:> >> Quoting Jay :> >>> >>> I know this area has been brewing under the surface a while.> >>> I'll bring it up. :)> >>>> >>> I assume texts are read only?> >>> >> Yes.> >>> >>> I know lots of systems have read only strings.> >>> There are pluses and minus to them. They can be single-instanced.> >>> Some systems with read only strings have another type, such as> >>> "StringBuilder" or "StringBuffer".> >>> So -- I don't have a specific question, but maybe a mutable string> >>> "class" aka "type" is needed?Not necessarily in the language but in> >>> m3core or libm3?> >>> Maybe it's already there?> >> > CharSeq.T?> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 21:56:31 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:56:31 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Well I was lazy and did some math in the debugger and indeed one bit of carry or overflow is adequate, for addition and subtraction. You can do better with multiplicatio..and division I'd have to think a lot more about. It is an odd inconsistency between the Add and Subtract code below though.. I guess the reason is that carry will be 0 or 1, but borrow will be 0 or -1 and you want to convert -1 to +1. As well, carry/borrow should be sign extended if you run out of bits, so the -1 is used. It probably could be: add: < r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); > carry := ORD (carry # 0); r.x[i] := carry; subtract: < r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1);> if borrow # 0 then r.x[i] := Mask; borrow := 1; end no major difference. ? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 20:34:51 +0000 Tony..are you sure..I'm not sure what I said is true.It seems clear that the host integer size is well abstracted while interpreting target numbers. I am more certain that [-1 .. 1] is empty, and this is likely a problem in TInt.Subtract.. PROCEDURE Add (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); carry := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO carry := a.x[i] + b.x[i] + carry; r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign # b_sign) OR (a_sign = r_sign); END Add; PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); borrow := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO borrow := a.x[i] - b.x[i] - borrow; r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign = b_sign) OR (a_sign = r_sign); END Subtract;Is it not adequate to treat carry and borrow as one it, zero or non-zero?Thinking in decimal about addition -- 9 + 9 = 18.You can never overflow to 20, 30, 40, etc. For substraction 0 - 9 = -9, never -10 or lower. However "1" is a full decimal digit, not a bit.In this case, the digits are bytes. Aha, so maybe the problem is the "and"? Let's check pm3 and decm3 3.6 again..No, pm3 has the and too.. hm. I have to refresh some of my bit twiddling algorithms.. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 15:14:18 -0500 Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64-bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Feb 26 22:01:22 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 26 Feb 2008 16:01:22 -0500 Subject: [M3devel] volume of cm3-related email traffic In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: <47C437CE.1E75.00D7.1@scires.com> I appreciate all the work everyone is doing these days on cm3, but I am having a problem I'd like to describe. I'm getting a large number of cm3-related email messages relayed to me each day. In many cases, I'm getting two copies of each message because folks are also addressing the message to me in addition to the m3devel list. The email address I've put on the m3devel and m3commit lists is my work email address. So, the large number of messages is now interfering with my job. In the past, this wasn't a problem because there weren't very many messages. I know I could change my email address for these mail lists to a private home mailbox, but I would not be able to check this box as frequently. Before I take this action, here are some suggestions I have: 1. Don't include the original sender on your reply; instead, just address to m3devel [I know I've been guilty about just lazily hitting the reply button without deleting the extra addresses, so this suggestion applies to me as well.] 2. Try not to use m3devel as a blog for a steady-stream of thought. Maybe we should setup a blog or something for this type of activity. 3. Try to think through and test your changes throughly to cut down on the number of commits. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Feb 26 22:28:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 26 Feb 2008 22:28:56 +0100 (CET) Subject: [M3devel] Is the climate right for a new promotion? In-Reply-To: <47C45BB4.40009@wichita.edu> References: <47C45BB4.40009@wichita.edu> Message-ID: On Tue, 26 Feb 2008, Rodney M. Bates wrote: > I have been thinking lately that the climate might be right for a new > attempt to promote Modula 3. I see two major trends and a small one > that suggest this. Promoting Modula-3 is always a good idea. But competition is hard. There are Ada and Eiffel which also follow the safety approach, but are still close to common imperative thinking. But also the Haskell community claims that it has the answer to safety issues and to parallelity. In functional programming you get more guarantees for free, but you have to pay with efficiency. However, there is constant progress in this respect. From my perspective, Modula-3's selling points against Ada and Eiffel are (relative) simplicity, and compared with functional programming Modula-3 may attract people by a conservative (imperative) programming style. From rcoleburn at scires.com Tue Feb 26 22:39:06 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 26 Feb 2008 16:39:06 -0500 Subject: [M3devel] CM3 package dependicies In-Reply-To: <1204020054.7354.2.camel@hias.m3w.org> References: <1204020054.7354.2.camel@hias.m3w.org> Message-ID: <47C440A7.1E75.00D7.1@scires.com> Yes, I too would like to know if this is solved. I had asked about this earlier when working on a nice way to keep the scripts up-to-date for rebuilding everything. Regards, Randy >>> Dragi?a Duri* 2/26/2008 5:00 AM >>> I am trying to figure out systematic way to map dependicies of packages so I can make nice hierarchy for RPM building... It's not too hard to map it out from m3makefiles, but it will be much better if someone already solved it :). Is there such a map already out there? TIA, dd -- Dragi?a Duri* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:10:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:10:30 -0500 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: <3AC8BC28-2E71-4E46-8E4C-5E17266721E2@cs.purdue.edu> The constants MOne, etc are used explicitly with specific precision by the compiler front-end. These constants indicate that they have a certain number of significant bytes in their representation. If you truncate the 8 bytes to 4 bytes for 32-bit then we know that the value will still be correct. Making it length 1 breaks the use of the contants in both 32-bit and 64-bit representations. These changes were made when I put in the LONGINT support -- that's why they are different from PM3. On Feb 26, 2008, at 2:53 PM, Jay wrote: > I haven't tested this but it looks very suspicious.. > When targeting 64 bit targets, the compiler thinks [-1 .. 1] is > empty. > When compiling things like "compare" functions. > I didn't debug it but just looked at the code. > > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v > retrieving revision 1.4 > diff -r1.4 TInt.i3 > 26c26 > < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; > --- > > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff, > 16_ff,16_ff,16_ff,16_ff}}; > > > another fix might be: > > > > MOne = Int{1, IBytes{16_ff}}; > > IBytes used to be 16 bit integers but now is 8 bit integers. > PM3 has: > > Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; > One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; > MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; > > which seems adequate for what is likely going on in these parts. > > I believe ".." fills with zeros, not the previous value. > > Also, is this objectionable? > > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v > retrieving revision 1.2 > diff -r1.2 TextLiteral.i3 > 15c15 > < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; > --- > > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - > 32; *) > > Maybe. The 32 bit compiler doesn't like such large types (that > follow from the use of this). > Maybe preferable to allow 32 bit hosted compiler to allow 64 bit > sized types? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Tue, 26 Feb 2008 18:53:58 +0000 > Subject: [M3devel] tangential 64 bit... > > alpha/osf doesn't work because basictypes/ctypes has a problem with > the 32bit or 64bit types. > specifically "unsigned long" is "empty" for some reason and many > errors cascade from that. > > if you change: > unsigned_int = [16_0 .. 16_ffffffff]; > to > unsigned_int = [16_0 .. 16_fffffffe]; > > you get: > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/TWord.m3", line 199 > *** > > Presumably fixing this first problem is the first step in any "real" > 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem > should just be fixed as a matter of course. > > I know this is the least of anyone's concerns.. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:14:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:14:37 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: <1C38F3E3-1E39-459D-879D-118C9D871E55@cs.purdue.edu> Legal depends on context, as you note. If you are able to see the representation of a given text then you can mess with it accordingly. The pointers for these are not to readonly memory. Note that you probably will break things if you try to write to TextLiteral.T.buf, since that might be readonly. Here be dragons, but my point was that every text has an underlying representation that may or may not be sensibly mutable. I am a strong believer in TEXT being immutable in the general case. On Feb 26, 2008, at 3:35 PM, Jay wrote: > Is that legal or is that subverting things? > It depends on the context? > Can the pointers be to read only memory in the code? > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: mika at async.caltech.edu > > Date: Tue, 26 Feb 2008 15:16:47 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] text inefficiency? good mutable string > type? arrays? > > > > ARRAY OF CHAR/WIDECHAR? > > > > These are available in the various Text implementations. For exampe, > > Text8.T.contents. One can freely mutate these at leisure and the > > higher-level text will appear to change! > > > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > > > > > Olaf Wagner writes: > > >> Quoting Jay : > > >> > > >>> I know this area has been brewing under the surface a while. > > >>> I'll bring it up. :) > > >>> > > >>> I assume texts are read only? > > >> > > >> Yes. > > >> > > >>> I know lots of systems have read only strings. > > >>> There are pluses and minus to them. They can be single- > instanced. > > >>> Some systems with read only strings have another type, such as > > >>> "StringBuilder" or "StringBuffer". > > >>> So -- I don't have a specific question, but maybe a mutable > string > > >>> "class" aka "type" is needed?Not necessarily in the language > but in > > >>> m3core or libm3? > > >>> Maybe it's already there? > > > > > > CharSeq.T? > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:18:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:18:24 -0500 Subject: [M3devel] volume of cm3-related email traffic In-Reply-To: <47C437CE.1E75.00D7.1@scires.com> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> <47C437CE.1E75.00D7.1@scires.com> Message-ID: Sounds like good practice to me! [Note that I am replying only to m3devel. :-) ] On Feb 26, 2008, at 4:01 PM, Randy Coleburn wrote: > I appreciate all the work everyone is doing these days on cm3, but I > am having a problem I'd like to describe. > I'm getting a large number of cm3-related email messages relayed to > me each day. In many cases, I'm getting two copies of each message > because folks are also addressing the message to me in addition to > the m3devel list. > > The email address I've put on the m3devel and m3commit lists is my > work email address. So, the large number of messages is now > interfering with my job. In the past, this wasn't a problem because > there weren't very many messages. > > I know I could change my email address for these mail lists to a > private home mailbox, but I would not be able to check this box as > frequently. Before I take this action, here are some suggestions I > have: > > 1. Don't include the original sender on your reply; instead, just > address to m3devel > [I know I've been guilty about just lazily hitting the reply button > without deleting the extra addresses, so this suggestion applies to > me as well.] > > 2. Try not to use m3devel as a blog for a steady-stream of > thought. Maybe we should setup a blog or something for this type of > activity. > > 3. Try to think through and test your changes throughly to cut down > on the number of commits. > > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:43:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:43:17 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> I suppose the question here is how often you exceed the 256-character stack-allocated buffer size? If not often then occasionally allocating in the heap is not a huge problem. I'm not too fussed about this anyway because generational GC will quickly reclaim things that die as young as this buffer does. I think you underestimate the effectiveness of modern GC algorithms. Anyway, optimizing here for short nm texts presumably handles the common case. Why work hard to optimize the uncommon case? On Feb 25, 2008, at 10:38 AM, Jay wrote: > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > Here is some apparently typical code: > > PROCEDURE Escape (nm: TEXT): TEXT = > VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (nm = NIL) THEN RETURN NIL; END; > len := Text.Length (nm); > IF (len + len <= NUMBER (buf)) > THEN RETURN DoEscape (nm, len, buf); > ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + > len)^); > END; > END Escape; > > PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF > CHAR): TEXT = > VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; > BEGIN > Text.SetChars (buf, nm); > FOR i := 0 TO len-1 DO > IF (buf[i] = BackSlash) THEN INC (n_escapes); END; > END; > IF (n_escapes = 0) THEN RETURN nm; END; > src := len - 1; > dest := src + n_escapes; > WHILE (src > 0) DO > c := buf[src]; DEC (src); > buf[dest] := c; DEC (dest); > IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); > END; > END; > RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); > END DoEscape; > > > Look at how inefficient this is. > For a long string it makes a heap allocation, even if in the end it > makes no changes to the string. > For any length string it copies it out to an array. > Then if there are any changes, it copies it again, probably into > heap, likely the input immediately becoming garbage. > Heap allocation may be fast, but building up garbage and causing > more work for the garbage collector I assume is bad. > And if the string had no backslashes, it's all a big waste. > > I assume texts are read only? > > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > > > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed? > Not necessarily in the language but in m3core or libm3? > Maybe it's already there? > > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a > good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => > wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not > characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Feb 27 00:14:31 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 26 Feb 2008 17:14:31 -0600 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: <47C49D57.4090600@wichita.edu> Mutating the Text implementations certainly could subvert the expected semantics of TEXT, for other TEXT values you might not expect to have any relation to what you are doing. But in my view, the much more important point is that ARRAY OF CHAR/ WIDECHAR, where you create your own values, are the mutable strings in Modula-3. You can pretty much do anything you want with this, including writing your own string abstraction, with different internal representation. In fact, I have done so, highly tailored to an application with specific, known performance characteristics and usage patterns. Jay wrote: > Is that legal or is that subverting things? > It depends on the context? > Can the pointers be to read only memory in the code? > > - Jay > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > To: mika at async.caltech.edu > > Date: Tue, 26 Feb 2008 15:16:47 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] text inefficiency? good mutable string type? > arrays? > > > > ARRAY OF CHAR/WIDECHAR? > > > > These are available in the various Text implementations. For exampe, > > Text8.T.contents. One can freely mutate these at leisure and the > > higher-level text will appear to change! > > > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > > > > > Olaf Wagner writes: > > >> Quoting Jay : > > >> > > >>> I know this area has been brewing under the surface a while. > > >>> I'll bring it up. :) > > >>> > > >>> I assume texts are read only? > > >> > > >> Yes. > > >> > > >>> I know lots of systems have read only strings. > > >>> There are pluses and minus to them. They can be single-instanced. > > >>> Some systems with read only strings have another type, such as > > >>> "StringBuilder" or "StringBuffer". > > >>> So -- I don't have a specific question, but maybe a mutable string > > >>> "class" aka "type" is needed?Not necessarily in the language but in > > >>> m3core or libm3? > > >>> Maybe it's already there? > > > > > > CharSeq.T? > > > > > ------------------------------------------------------------------------ > Climb to the top of the charts! Play the word scramble challenge with > star power. Play now! > -- ------------------------------------------------------------- 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 Wed Feb 27 00:46:26 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 23:46:26 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> Message-ID: Tony, what about the need to copy? The inability to iterate through characters without a function call per character? I guess though, from what you pointed out, a read only direct pointer is viable. And that removes the 256 character stack usage -- which is a bit piggy as it is. So then..I guess the next step in some compromise here is that it should perhaps be viable to get a read only pointer to a string (maybe already the case), compute the required size of the new one (follows naturally), and then be able to split up allocation and filling in of a string, a function to allocate and get a direct pointer, then fill in your data, then "seal" the text making it read only. And I guess really you can just carefully use the "subversive" method here -- up to you to not pass the "unsealed" text off to anyone else until you are done writing to it. Then just to deal with the varying representation but as I was suggesting, maybe that can be forced somehow. Maybe creation can specify an encoding, or the "get buffer" function could -- though ideally there is just one, not two. The stack vs. heap behavior is also not ideal in that it's nice for the performance of something to scale linearly with input, not suddenly slow way down when data exceeds some arbitrary threshold. Granted, a lot of code just starts failing, so merely slowing down is "progress". As well, eventually you end up swapping to disk, if you don't first run out of address space, so there will be limits at which things slow down or fail, just that they ought to be fairly large. I also rather hoped/assumed that compile time text constants were formed constant-ly by the compiler, that the compiler knows their runtime layout. I realize the division of labor between compiler and runtime can be made at varying points, with varying resulting flexibility, but also varying resulting efficiency. - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 17:43:17 -0500Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays? I suppose the question here is how often you exceed the 256-character stack-allocated buffer size? If not often then occasionally allocating in the heap is not a huge problem. I'm not too fussed about this anyway because generational GC will quickly reclaim things that die as young as this buffer does. I think you underestimate the effectiveness of modern GC algorithms. Anyway, optimizing here for short nm texts presumably handles the common case. Why work hard to optimize the uncommon case? On Feb 25, 2008, at 10:38 AM, Jay wrote: I know this area has been brewing under the surface a while.I'll bring it up. :) Here is some apparently typical code: PROCEDURE Escape (nm: TEXT): TEXT = VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; BEGIN IF (nm = NIL) THEN RETURN NIL; END; len := Text.Length (nm); IF (len + len <= NUMBER (buf)) THEN RETURN DoEscape (nm, len, buf); ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + len)^); END; END Escape;PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF CHAR): TEXT = VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; BEGIN Text.SetChars (buf, nm); FOR i := 0 TO len-1 DO IF (buf[i] = BackSlash) THEN INC (n_escapes); END; END; IF (n_escapes = 0) THEN RETURN nm; END; src := len - 1; dest := src + n_escapes; WHILE (src > 0) DO c := buf[src]; DEC (src); buf[dest] := c; DEC (dest); IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); END; END; RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); END DoEscape;Look at how inefficient this is.For a long string it makes a heap allocation, even if in the end it makes no changes to the string.For any length string it copies it out to an array.Then if there are any changes, it copies it again, probably into heap, likely the input immediately becoming garbage.Heap allocation may be fast, but building up garbage and causing more work for the garbage collector I assume is bad.And if the string had no backslashes, it's all a big waste. I assume texts are read only? I know lots of systems have read only strings.There are pluses and minus to them. They can be single-instanced.Some systems with read only strings have another type, such as "StringBuilder" or "StringBuffer".So -- I don't have a specific question, but maybe a mutable string "class" aka "type" is needed?Not necessarily in the language but in m3core or libm3?Maybe it's already there? I just spent a few hours diddling with arrays of chars.Unfortunately they are not resizable.It was not entirely satisfactory. Besides the array I had to pass around a length and a start.Wrapping this up in one record TYPE MutableString= ... might be a good idea. For more efficient read only access, would it be reasonable for the runtime to materialize on-demand 8 bit and 16 bit representations of a string if a user calls some new thing like Text.GetDirectA (t: TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF WIDECHAR? Throw an exception if the string cannot be represented with 8 bit characters? Or use utf8? Besides, I know I'm a big predictable whiner but I like how this works in Windows..It may not have been as seamless, but it works and it really doesn't tend to break or slow down existing code.roughly: "foo" is an 8 bit string of type char* (or const char* or possibly const char[4]) L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) "L" for "long" aka "wide" Functions must be written to specifically use one or the other.In C++ you can templatize. There is std::string and std::wstring that are template instantiations.Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc.And really there's no point in 8 bit strings.If you have a blob, that's an array of bytes or something, not characters. It works. Utf8 is another seemingly popular route but I think it's a hack.I think mostly people don't touch their code and say, voila, it's utf8, and they only really support the same old English or possibly 8 bit characters (some European characters).Granted, to some extent, this does work, as long as you don't do anything with the string but strlen, strcpy, and some others and pass it to code that does treat it correctly. Still, variably sized encodings seem like a bad idea here, and 16 bits per character seem affordable enough. And yes, I know that Unicode is actually know 20 bits per character and some characters take two wchar_ts but I try to ignore that...And I know there is a lot of existing code, but sometimes there is a need for progress too... Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 27 00:57:59 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 23:57:59 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <47C49D57.4090600@wichita.edu> References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> <47C49D57.4090600@wichita.edu> Message-ID: Right that arrays of chars/widechars make good strings, however you run into the problem of what is the ubiquitous type that is good to have around because any other code can deal with it. It's often nice to have fewer types and therefore more easier interoperability among code -- avoid any thick translation layer or conversion of data back and forth. It's tough though of course, since not one size (type) fits all. It seems annoying and wasteful, but also plain ok, for everyone to have their own string, array, list, etc. types. My "crazy" view though is that it is better to have one string class per programmer than any programmer with no string type to use. Fewer types/libraries would be preferable, but the alternative of anyone having none is worse. It is easy enough to write these things for yourself if there really is no acceptable existing option. (though the ease with which folks dismiss existing alternatives is also bad) Some people claim they need to leave the writing of string/array/list to the super-skilled library developers, but I don't think so. The line between library producer and library consumer is not always so clear. I may not be capable of whipping together a windowing system or a threading library or compiler, but string and growable array are plenty easy enough. :) Sometimes the library writers aren't even so good.. I remember reading, if I interpreted it correctly, how the Python developers were so proud of their growable arrays that are so efficient because they grow in chunks of constant size larger than 1...except that's not actually how you write an efficient growable array, you have to grow exponentially -- by a factor greater than 1, such as 2 or 3 or 1.5. This is for the scenario of folks adding one element at a time. I also found Modula-3 arrays to be a little disappointing so far. Could be me at this point. I'd like to be able to change their length and possibly remove elements from the start without a copy. I suppose that involves a dreaded "interior pointer" and gc problems. I know SOME about SUBARRAYS but so far, it seems SUBARRAY can only be passed as parameters or use in "surprisingly powerful" assignment: subarray(a, offset, length) := subarray(b, offset, length). It seems I cannot assign, like, a subarray to a reference. a: array [0..9] of integer, b : ref array [8..9] of integer := subarray(a, 8) ? I'll have to look into that too.. Really I was going to try to shut up today at Randy's request but folks responded.. :) - Jay > Date: Tue, 26 Feb 2008 17:14:31 -0600> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays?> > Mutating the Text implementations certainly could subvert the expected> semantics of TEXT, for other TEXT values you might not expect to have> any relation to what you are doing.> > But in my view, the much more important point is that ARRAY OF CHAR/> WIDECHAR, where you create your own values, are the mutable strings> in Modula-3. You can pretty much do anything you want with this,> including writing your own string abstraction, with different internal> representation. In fact, I have done so, highly tailored to an> application with specific, known performance characteristics and> usage patterns.> > Jay wrote:> > Is that legal or is that subverting things?> > It depends on the context?> > Can the pointers be to read only memory in the code?> > > > - Jay> > > > > > ------------------------------------------------------------------------> > > > > From: hosking at cs.purdue.edu> > > To: mika at async.caltech.edu> > > Date: Tue, 26 Feb 2008 15:16:47 -0500> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] text inefficiency? good mutable string type? > > arrays?> > >> > > ARRAY OF CHAR/WIDECHAR?> > >> > > These are available in the various Text implementations. For exampe,> > > Text8.T.contents. One can freely mutate these at leisure and the> > > higher-level text will appear to change!> > >> > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote:> > >> > > > Olaf Wagner writes:> > > >> Quoting Jay :> > > >>> > > >>> I know this area has been brewing under the surface a while.> > > >>> I'll bring it up. :)> > > >>>> > > >>> I assume texts are read only?> > > >>> > > >> Yes.> > > >>> > > >>> I know lots of systems have read only strings.> > > >>> There are pluses and minus to them. They can be single-instanced.> > > >>> Some systems with read only strings have another type, such as> > > >>> "StringBuilder" or "StringBuffer".> > > >>> So -- I don't have a specific question, but maybe a mutable string> > > >>> "class" aka "type" is needed?Not necessarily in the language but in> > > >>> m3core or libm3?> > > >>> Maybe it's already there?> > > >> > > > CharSeq.T?> > >> > > > > > ------------------------------------------------------------------------> > Climb to the top of the charts! Play the word scramble challenge with > > star power. Play now! > > > > -- > -------------------------------------------------------------> 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 _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Feb 27 10:41:10 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 Feb 2008 10:41:10 +0100 Subject: [M3devel] bootstrap from IL code? Message-ID: <1204105270.13580.10.camel@hias.m3w.org> If I remember correctly (fog of advanced age and all:), we used to have bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did not depend on installed Modula-3 compiler. Are there some scripts to make such bootstrap archive now? So we can make self-buildable package without Modula-3 compiler packaged in. dd -- Dragi?a Duri? From dragisha at m3w.org Wed Feb 27 10:57:35 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 Feb 2008 10:57:35 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204105270.13580.10.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> Message-ID: <1204106255.13580.13.camel@hias.m3w.org> I see where it is... But, somebody probably already did it... Is there short script or howto on making cm3-min substitute based on IL? And why we don't have cm3-min-*-*... buildable with only gcc on-system?? IMO, this would help anybody building system. dd On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote: > If I remember correctly (fog of advanced age and all:), we used to have > bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did > not depend on installed Modula-3 compiler. > > Are there some scripts to make such bootstrap archive now? So we can > make self-buildable package without Modula-3 compiler packaged in. > > dd > -- Dragi?a Duri? From wagner at elegosoft.com Wed Feb 27 11:35:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 11:35:03 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204106255.13580.13.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> Message-ID: <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Quoting Dragi?a Duri? : > I see where it is... But, somebody probably already did it... Is there > short script or howto on making cm3-min substitute based on IL? > > And why we don't have cm3-min-*-*... buildable with only gcc on-system?? > IMO, this would help anybody building system. This was in PM3, but has never been integrated into CM3. If you'd like to work on it, it will be great. We could even come to the point were we build distributions for most targets on one platforms (possibly with the exception of crossing 32->64 bit boundaries). When extending the existing scripts, please make sure that the existing interfaces and functions keep working. Olaf > dd > > On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote: >> If I remember correctly (fog of advanced age and all:), we used to have >> bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did >> not depend on installed Modula-3 compiler. >> >> Are there some scripts to make such bootstrap archive now? So we can >> make self-buildable package without Modula-3 compiler packaged in. >> >> dd -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 27 11:54:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 10:54:41 +0000 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Message-ID: DEC M3.6 was distributed as assembly and some C files. It could just as well be .obj files. Most of the C was the implementation of quake, but maybe also dtoa.c, hand.c, and such. There is already a lot here, there is something like having the build stop either right before running as or right before ld, and then somehow resuming after all the files are copied to the target. I thought Olaf would answer "more positively", and I thought the stuff in scripts/* does about what you want, and I believe there is good documentation on exactly this. I realize that in what I said there, there's a mystery as to how to "resume" on the target. Cm3 could about some big .sh or .cmd file easily enough. Maybe the difference is just the amount of "friendliness" of the process? Not easy enough for "beginners"? I really expect we'll, um, "cross" the 32/64 boundary relatively soon in terms of, um, cross building. Unless I'm badly mistaken as to the general design of cm3. It sure looks prepared to do correct compile time math how the target would. And heck, maybe it could just skip constant propagation if not? (gcc also uses a lib in to do correct floating point target math, one of the dependencies I was initially missing, ./configure complains clearly) Not sure, it might be matters of correctness and not just optimization that require target math. For array maximum sizes, if that was the only problem, probably reasonable to just have 32 bit limits (TextLiteral.i3 has a problem building because of this.) I need to try out NT386GNU's GUI stuff (X Windows), make sure all of "std" can build and run for some reasonably large set (a lot already builds), and fix the Windows bitmap problem, and maybe PPC_LINUX dynamic linking and get a current distribution out, but I think getting ALPHA_OSF to compile (but not assemble or link) is among the next good things to try, as a stepping stone to a "real" 64 bit target such as, as I said, AMD64, IA64, POWER64, SPARC64. AMD64 of course I think is the most interesting, the cheapest hardware and it runs "everything" -- Windows, Linux, I think Solaris -- and in all cases "both" architectures even, via multi boot and always/sometimes "one boot". (I know this is true of Windows, I believe it is optional on Linux depending on distribution/configuration, they call it "biarch", and unsure about Solaris, not sure it has an AMD64 port or not, but certainly it has x86.) IF IF IF I'm right as to how the compiler works, this really shouldn't be a big deal.. We'll see.. - Jay > Date: Wed, 27 Feb 2008 11:35:03 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] bootstrap from IL code?> > Quoting Dragi?a Duri? :> > > I see where it is... But, somebody probably already did it... Is there> > short script or howto on making cm3-min substitute based on IL?> >> > And why we don't have cm3-min-*-*... buildable with only gcc on-system??> > IMO, this would help anybody building system.> > This was in PM3, but has never been integrated into CM3. If you'd> like to work on it, it will be great. We could even come to the point> were we build distributions for most targets on one platforms (possibly> with the exception of crossing 32->64 bit boundaries).> > When extending the existing scripts, please make sure that the existing> interfaces and functions keep working.> > Olaf> > > dd> >> > On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote:> >> If I remember correctly (fog of advanced age and all:), we used to have> >> bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did> >> not depend on installed Modula-3 compiler.> >>> >> Are there some scripts to make such bootstrap archive now? So we can> >> make self-buildable package without Modula-3 compiler packaged in.> >>> >> dd> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 27 14:43:12 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 14:43:12 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204112891.13580.27.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> Message-ID: <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Wed, 2008-02-27 at 11:35 +0100, Olaf Wagner wrote: >> Quoting Dragi?a Duri? : >> >> > I see where it is... But, somebody probably already did it... Is there >> > short script or howto on making cm3-min substitute based on IL? >> > >> > And why we don't have cm3-min-*-*... buildable with only gcc on-system?? >> > IMO, this would help anybody building system. >> >> This was in PM3, but has never been integrated into CM3. If you'd >> like to work on it, it will be great. We could even come to the point >> were we build distributions for most targets on one platforms (possibly >> with the exception of crossing 32->64 bit boundaries). > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had problems > cross compiling on 32bit for 64bit... I've made some quick&dirty fix so > it was IL code being archived/transferred/compiled, and not assembly as > was usual at time... John Polstra extended and integrated that trick > into building system of PM3, I don't know where that code is now. > Anybody? It should be in the PM3 repository, which is hosted and available at the elego WWW servers, too: http://modula3.elegosoft.com/pm3/ There hasn't been much activity in recent years though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Feb 27 15:41:02 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 27 Feb 2008 09:41:02 -0500 Subject: [M3devel] bootstrap from IL code? In-Reply-To: References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Message-ID: Take a look at the code in pm3/language/modula3/m3compiler/ m3bootstrap: this would build a bunch of assembler files and a Makefile for bootstrapping without the M3 compiler. On Feb 27, 2008, at 5:54 AM, Jay wrote: > DEC M3.6 was distributed as assembly and some C files. It could just > as well be .obj files. > Most of the C was the implementation of quake, but maybe also > dtoa.c, hand.c, and such. > There is already a lot here, there is something like having the > build stop either right before running as or right before ld, and > then somehow resuming after all the files are copied to the target. > I thought Olaf would answer "more positively", and I thought the > stuff in scripts/* does about what you want, and I believe there is > good documentation on exactly this. I realize that in what I said > there, there's a mystery as to how to "resume" on the target. Cm3 > could about some big .sh or .cmd file easily enough. > Maybe the difference is just the amount of "friendliness" of the > process? Not easy enough for "beginners"? > > > I really expect we'll, um, "cross" the 32/64 boundary relatively > soon in terms of, um, cross building. > Unless I'm badly mistaken as to the general design of cm3. > It sure looks prepared to do correct compile time math how the > target would -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 27 21:02:00 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 20:02:00 +0000 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Message-ID: > Date: Feb 2008 > Quoting Dragi?a Duri? : > > >> were we build distributions for most targets on one platforms (possibly > >> with the exception of crossing 32->64 bit boundaries). > > > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had problems > > cross compiling on 32bit for 64bit... I've made some quick&dirty fix so These problems have all been fixed in gcc by now, right? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your HotmailR-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 27 21:30:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 27 Feb 2008 15:30:26 -0500 Subject: [M3devel] bootstrap from IL code? In-Reply-To: References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Message-ID: <3F1B6366-DA7A-42A8-B8CB-545B76E6D9AE@cs.purdue.edu> Should be fixed, yes. On Feb 27, 2008, at 3:02 PM, Jay wrote: > > Date: Feb 2008 > > Quoting Dragi?a Duri? : > > > > >> were we build distributions for most targets on one platforms > (possibly > > >> with the exception of crossing 32->64 bit boundaries). > > > > > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had > problems > > > cross compiling on 32bit for 64bit... I've made some > quick&dirty fix so > > > These problems have all been fixed in gcc by now, right? > > > - Jay > > Need to know the score, the latest news, or you need your HotmailR- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 27 22:23:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 22:23:05 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: <47C440A7.1E75.00D7.1@scires.com> References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> Message-ID: <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Quoting Randy Coleburn : > Yes, I too would like to know if this is solved. > I had asked about this earlier when working on a nice way to keep the > scripts up-to-date for rebuilding everything. > Regards, > Randy Perhaps I misunderstood what you were asking for; I've checked-in a package dependency list in scripts/cm3-pkg-deps now. The actual package paths relative to ROOT can be found in scripts/PKGS. A list of all packages is kept in scripts/pkginfo.txt. Let's see if this is useful. I'll add the program to extract the dependencies soon. Olaf >>>> Dragi?a Duri* 2/26/2008 5:00 AM >>> > I am trying to figure out systematic way to map dependicies of > packages > so I can make nice hierarchy for RPM building... It's not too hard to > map it out from m3makefiles, but it will be much better if someone > already solved it :). Is there such a map already out there? > > TIA, > dd > -- > Dragi?a Duri* > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 27 22:32:22 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 21:32:22 +0000 Subject: [M3devel] CM3 package dependicies In-Reply-To: <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Message-ID: > A list of all packages is kept in scripts/pkginfo.txt. I also plan to make scripts/python and scripts/win use pkginfo.txt, esp. scripts/python. If anyone cares, please speak up. I would also like filtering to be driven by pkginfo.txt, however that seems of quite low importance, esp. in ratio to how obvious the design is (not entirely obvious, like if something really really simple will suffice or be too ambiguous). Also, Olaf, about two months ago I believe you said "std should be all". I hesitated. "Are you certain?" I kind of also think filtering needs a command line override. Maybe just that do-pkg should do no filtering? You know, I always set OMIT_GCC and I occasionally want to build m3cc. I do like how sh can set env vars on the command line for just that invocation, but I'm not willing to switch to sh just for that feature with all that I'd lose. Again, though, I've settled into the larger consensus that this stuff doesn't matter too much. :) - Jay > Date: Wed, 27 Feb 2008 22:23:05 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] CM3 package dependicies> > Quoting Randy Coleburn :> > > Yes, I too would like to know if this is solved.> > I had asked about this earlier when working on a nice way to keep the> > scripts up-to-date for rebuilding everything.> > Regards,> > Randy> > Perhaps I misunderstood what you were asking for; I've checked-in> a package dependency list in scripts/cm3-pkg-deps now. The actual> package paths relative to ROOT can be found in scripts/PKGS.> A list of all packages is kept in scripts/pkginfo.txt.> > Let's see if this is useful.> > I'll add the program to extract the dependencies soon.> > Olaf> > >>>> Dragi?a Duri* 2/26/2008 5:00 AM >>>> > I am trying to figure out systematic way to map dependicies of> > packages> > so I can make nice hierarchy for RPM building... It's not too hard to> > map it out from m3makefiles, but it will be much better if someone> > already solved it :). Is there such a map already out there?> >> > TIA,> > dd> > --> > Dragi?a Duri* > >> >> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 00:14:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 00:14:49 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Message-ID: <20080228001449.v1fpl1gwg0c8gwcg@mail.elegosoft.com> Quoting Jay : >> A list of all packages is kept in scripts/pkginfo.txt. > I also plan to make scripts/python and scripts/win use pkginfo.txt, > esp. scripts/python. > If anyone cares, please speak up. > I would also like filtering to be driven by pkginfo.txt, however > that seems of quite low importance, esp. in ratio to how obvious the > design is (not entirely obvious, like if something really really > simple will suffice or be too ambiguous). > > Also, Olaf, about two months ago I believe you said "std should be all". > I hesitated. "Are you certain?" Seems I was wrong there. When we first made the system run again, we thought of `std' to be the compilable and usable packages. Now all packages should at least compile. Perhaps we should drop it or define a more sensible set of `standard packages'? > I kind of also think filtering needs a command line override. > Maybe just that do-pkg should do no filtering? Sounds OK. Or add a -f option. > You know, I always set OMIT_GCC and I occasionally want to build m3cc. > I do like how sh can set env vars on the command line for just that > invocation, but I'm not willing to switch to sh just for that > feature with all that I'd lose. We'll get you around in the end. This is Unix. Resistance is futile :-) > Again, though, I've settled into the larger consensus that this > stuff doesn't matter too much. :) Right :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 28 09:31:32 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:31:32 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 09:44:11 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:44:11 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 09:59:47 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:59:47 +0000 Subject: [M3devel] FW: put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000 pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 10:25:45 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 09:25:45 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: Is it easy enough for the commit mails to contain links to view all of the diffs described?That's be super duper nice. I find browsing the cvsweb very inefficient. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:59:47 +0000 truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000 pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 10:33:15 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 10:33:15 +0100 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: <20080228103315.tkxlxp32144kgsk8@mail.elegosoft.com> Quoting Jay : > Is it easy enough for the commit mails to contain links to view all > of the diffs described?That's be super duper nice. I'd say that depends on somebody providing the appropriate patch for the CVS commit hook script on birch.elegosoft.com ;-) Olaf PS: You can view the diffs related to every commit via the tinderbox page in the `Guilty' column though. That's quite convenient. > I find browsing the cvsweb very inefficient. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 28 14:03:07 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 13:03:07 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: Done.On birch, time sh -c "./do-pkg.sh realclean libm3 && ./do-pkg.sh buildship libm3" seems go from about 35 seconds to about 15 seconds.Let me know what improvements people see? OMIT_GCC=yes do-cm3-std probably is the best test.alarmthreads platforms (PPC_LINUX), no change (still rebuilding actually). NT386GNU still seems just as slow. At some point I will try batching up the cm3cg and/or as calls. Maybe via a wrapper on Windows only that then just makes n Win32 CreateProcess calls instead of n Cygwin vforks. It might be nice to have Quake callouts for before_first_compile, after_last_compile, before_first_assemble, after_last_assemble, though this brings up that there should perhaps be begin_package/end_package, for cm3 to become a multi-package builder..and then, really, multi-threaded, so there'd have to be maybe extra state variables passed around, maybe. (and then Cygwin's waitpid not being threadsafe breaks this...) (For prototyping, before_first compile is implied, after_last_compile/assemble is implied by make_lib/skip_lib/link, so any queuing up could be flushed at that point. Goal here being not to reduce process creates, but cygwin processes created from cygwin processes. oh, and I just realized, cm3cg should probably mark all data as "no copy" when targeting Cygwin. That might help a bunch.) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Tue, 29 Jan 2008 08:08:38 -0500> To: mika at async.caltech.edu> > Indeed. We definitely need to fix this...> > > On Jan 29, 2008, at 5:45 AM, Mika Nystrom wrote:> > > Jay writes:> > ..> >> It is painfully noticable how much more slowly NT386GNU m3cc > >> builds than NT=> >> 386MINGNU m3cc, presumably due to the underlying slower bash/sed/ > >> make etc.> > ..> >> > are you sure it's not the Thread.Sleep(0.1d0) in Process.Wait?> >> > Mika> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 14:28:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 14:28:55 +0100 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Quoting Jay : > Done.On birch, time sh -c "./do-pkg.sh realclean libm3 && > ./do-pkg.sh buildship libm3" > seems go from about 35 seconds to about 15 seconds.Let me know what > improvements people see? > OMIT_GCC=yes do-cm3-std probably is the best test.alarmthreads > platforms (PPC_LINUX), no change (still rebuilding actually). That's great. I'll let you know this evening how it works for me. > NT386GNU still seems just as slow. IIRC, process creation (fork) was always really slow in Cygwin. You cannot expect to be better than the underlying platform :-/ > At some point I will try batching up the cm3cg and/or as calls. > Maybe via a wrapper on Windows only that then just makes n Win32 > CreateProcess calls instead of n Cygwin vforks. > It might be nice to have Quake callouts for before_first_compile, > after_last_compile, before_first_assemble, after_last_assemble, > though this brings up that there should perhaps be > begin_package/end_package, for cm3 to become a multi-package > builder..and then, really, multi-threaded, so there'd have to be > maybe extra state variables passed around, maybe. (and then Cygwin's > waitpid not being threadsafe breaks this...) What we really should do to speed things up on modern multi-core processors is to implement parallel compilation (both front-end and back-end) of sources. This should be possible now that we have native thread support in M3. It will probably need some design changes though; I haven't looked into it, though I often thought this was a missing feature. Olaf > (For prototyping, before_first compile is implied, > after_last_compile/assemble is implied by make_lib/skip_lib/link, so > any queuing up could be flushed at that point. Goal here being not > to reduce process creates, but cygwin processes created from cygwin > processes. oh, and I just realized, cm3cg should probably mark all > data as "no copy" when targeting Cygwin. That might help a bunch.) > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Feb 28 15:09:14 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 09:09:14 -0500 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> No, please don't do that!!!! I hate it when I get a huge file of diffs. The comment should be descriptive enough to let me know if I care about the diffs or not. As an emacs user it is trivial for me to browse diffs there if I *really* care. But e-mail is the *wrong* place for diffs!! On Feb 28, 2008, at 4:25 AM, Jay wrote: > Is it easy enough for the commit mails to contain links to view all > of the diffs described? > That's be super duper nice. > I find browsing the cvsweb very inefficient. > > - Jay > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: FW: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:59:47 +0000 > > truncated again! and possibly misformated.. > > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the privacy/size/same- > across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command line > option. I will always turn it on. :) > > - Jay > > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines or > does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number > yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 28 15:12:21 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 09:12:21 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: I'm not sure what you mean here... Please explain further... On Feb 28, 2008, at 8:03 AM, Jay wrote: > Done. > On birch, > time sh -c "./do-pkg.sh realclean libm3 && ./do-pkg.sh buildship > libm3" > > seems go from about 35 seconds to about 15 seconds. > Let me know what improvements people see? > OMIT_GCC=yes do-cm3-std probably is the best test. > alarmthreads platforms (PPC_LINUX), no change (still rebuilding > actually). > > NT386GNU still seems just as slow. > At some point I will try batching up the cm3cg and/or as calls. > Maybe via a wrapper on Windows only that then just makes n Win32 > CreateProcess calls instead of n Cygwin vforks. > It might be nice to have Quake callouts for before_first_compile, > after_last_compile, before_first_assemble, after_last_assemble, > though this brings up that there should perhaps be begin_package/ > end_package, for cm3 to become a multi-package builder..and then, > really, multi-threaded, so there'd have to be maybe extra state > variables passed around, maybe. (and then Cygwin's waitpid not being > threadsafe breaks this...) > > (For prototyping, before_first compile is implied, > after_last_compile/assemble is implied by make_lib/skip_lib/link, so > any queuing up could be flushed at that point. Goal here being not > to reduce process creates, but cygwin processes created from cygwin > processes. oh, and I just realized, cm3cg should probably mark all > data as "no copy" when targeting Cygwin. That might help a bunch.) > > - Jay > > > > > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] nt386gnu threads? > > Date: Tue, 29 Jan 2008 08:08:38 -0500 > > To: mika at async.caltech.edu > > > > Indeed. We definitely need to fix this... > > > > > > On Jan 29, 2008, at 5:45 AM, Mika Nystrom wrote: > > > > > Jay writes: > > > .. > > >> It is painfully noticable how much more slowly NT386GNU m3cc > > >> builds than NT= > > >> 386MINGNU m3cc, presumably due to the underlying slower bash/sed/ > > >> make etc. > > > .. > > > > > > are you sure it's not the Thread.Sleep(0.1d0) in Process.Wait? > > > > > > Mika > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Feb 28 19:22:50 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 19:22:50 +0100 Subject: [M3devel] multiple pkg roots? Message-ID: <1204222970.13580.62.camel@hias.m3w.org> Is it possible to ship to more than one location, and/or have system find package imported in list of locations, instead from one location? dd -- Dragi?a Duri? From jayk123 at hotmail.com Thu Feb 28 19:47:45 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 18:47:45 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> References: <20080228082322.3662910D46B6@birch.elegosoft.com> <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> Message-ID: Links, not diffs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] put full paths to source files in debug infoDate: Thu, 28 Feb 2008 09:09:14 -0500 No, please don't do that!!!! I hate it when I get a huge file of diffs. The comment should be descriptive enough to let me know if I care about the diffs or not. As an emacs user it is trivial for me to browse diffs there if I *really* care. But e-mail is the *wrong* place for diffs!! On Feb 28, 2008, at 4:25 AM, Jay wrote: Is it easy enough for the commit mails to contain links to view all of the diffs described?That's be super duper nice.I find browsing the cvsweb very inefficient. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:59:47 +0000truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 19:49:25 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 18:49:25 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Message-ID: > You cannot expect to be better than the underlying platform :-/ Cygwin is much slower than the underying platform I believe.. - Jay [snip] _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Feb 28 20:05:34 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 13:05:34 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] Message-ID: <47C705FE.7090005@wichita.edu> I don't understand what the need for these paths is. In every complete program, all the interfaces and all the modules must have unique simple names, otherwise code could not refer to them. With the filename matchup rules, this should make all the simple file names unique too. So any debug commands should never need a path. And using simple names avoids the problems of moving compiled code. Is it more output from the debugger you want? If so, this could no doubt be done by the debugger itself with the debug info as it was. It already contained one copy of the full path to the source file in each object file, though I don't know of a place the debugger uses this now. Yes, I know the filename/modulename rules don't actually apply for modules, but not following them is a bad practice. I've been around that block many times with Ada, and believe me, it's a nightmare. Furthermore, then you wouldn't be able to name things in the debugger as ModuleName.VarOrProcInModule, This construct does not exist in code but is very useful in debugging, especially when InterfaceName/ModuleName is not one-to-one, e.g. when a module exports >1 interface, etc. Jay wrote: > truncated again! and possibly misformated.. > > > > > ------------------------------------------------------------------------ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the > privacy/size/same-across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > ------------------------------------------------------------------------ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command > line option. I will always turn it on. :) > > - Jay > > ------------------------------------------------------------------------ > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines > or does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your Hotmail?-get > your "fix". Check it out. -- ------------------------------------------------------------- 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 dragisha at m3w.org Thu Feb 28 20:13:21 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 20:13:21 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? Message-ID: <1204226001.13580.64.camel@hias.m3w.org> I am probably missing it, and few of my last runs had some problems... So - what is current state of m3gdb on LINUXLIBC6? Working? Under fixing? TIA, dd -- Dragi?a Duri? From hosking at cs.purdue.edu Thu Feb 28 20:13:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 14:13:48 -0500 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> Message-ID: <4CD621A0-B1CA-4B2B-8C79-5B7CFD577186@cs.purdue.edu> Sorry, read your message too quickly. Yes, links might be nice.... :-) On Feb 28, 2008, at 1:47 PM, Jay wrote: > Links, not diffs. > > - Jay > > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] put full paths to source files in debug info > Date: Thu, 28 Feb 2008 09:09:14 -0500 > > No, please don't do that!!!! I hate it when I get a huge file of > diffs. The comment should be descriptive enough to let me know if I > care about the diffs or not. As an emacs user it is trivial for me > to browse diffs there if I *really* care. But e-mail is the *wrong* > place for diffs!! > > On Feb 28, 2008, at 4:25 AM, Jay wrote: > > Is it easy enough for the commit mails to contain links to view all > of the diffs described? > That's be super duper nice. > I find browsing the cvsweb very inefficient. > > - Jay > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: FW: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:59:47 +0000 > > truncated again! and possibly misformated.. > > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the privacy/size/same- > across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command line > option. I will always turn it on. :) > > - Jay > > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines or > does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number > yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 28 20:12:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 14:12:33 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <47C705FE.7090005@wichita.edu> References: <47C705FE.7090005@wichita.edu> Message-ID: <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> I concur with Rodney on this. There are deeper issues here than simply avoiding the need to use dir in gdb. On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > I don't understand what the need for these paths is. In every > complete > program, all the interfaces and all the modules must have unique > simple > names, otherwise code could not refer to them. With the filename > matchup > rules, this should make all the simple file names unique too. So any > debug commands should never need a path. And using simple names > avoids > the problems of moving compiled code. > > Is it more output from the debugger you want? If so, this could no > doubt > be done by the debugger itself with the debug info as it was. It > already > contained one copy of the full path to the source file in each > object file, > though I don't know of a place the debugger uses this now. > > Yes, I know the filename/modulename rules don't actually apply for > modules, > but not following them is a bad practice. I've been around that > block many > times with Ada, and believe me, it's a nightmare. Furthermore, then > you > wouldn't be able to name things in the debugger as > ModuleName.VarOrProcInModule, > This construct does not exist in code but is very useful in > debugging, especially > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > exports >1 > interface, etc. > > Jay wrote: >> truncated again! and possibly misformated.. >> >> ------------------------------------------------------------------------ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: RE: put full paths to source files in debug info >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> pps: "webinfo" (Reactor?) and assertion failures are affected by >> this also, but not fully. >> Before you would have gotten: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "WaitProcessCygwin.m3", line 16 >> *** >> but now you get: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> *** >> I'd say the realpath call (or whatever the portable Modula-3 >> library >> call is) should be moved up to m3front to address these, and the >> parse.c change undone. >> As well, I believe resolving symlinks is happening too but >> that >> wasn't the point, so something instead of realpath might be >> preferable. Like, just see if the string starts ".\" or "..\", it >> will almost always start "..\", and if so, prepend current working >> directory and then workout the dots. >> It may also be reasonable to provide paths to the compiler >> to remove >> from the starts of paths, which would likely address the symlink >> issue, since they are more likely to be nearer the start of the >> path >> than the middle or end. As well as partly the >> privacy/size/same-across-machines issues. >> In any case, I think this easy small change is already very >> useful >> progress. Or does everyone else just fill up .gdbinit with dir >> commands? It seems to me that it shouldn't even that difficult, >> even >> if it isn't very difficult. >> Agreed? >> - Jay >> >> ------------------------------------------------------------------------ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: re: put full paths to source files in debug info >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> ps: does anyone care that binaries built from different cvs >> checkouts, but otherwise identical source, will no longer match, >> unless perhaps they are "stripped"? >> If so, or if any of the other issues bug people, or any other >> problem is brought up or discovered, this can be made a command >> line option. I will always turn it on. :) >> - Jay >> >> ------------------------------------------------------------------------ >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> > To: m3commit at elegosoft.com >> > From: jkrell at elego.de >> > Subject: [M3commit] CVS Update: cm3 >> > >> > CVSROOT: /usr/cvs >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> > >> > Modified files: >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> > Scanner.m3 >> > >> > Log message: >> > put full paths to source files in debug info >> > >> > This has the minor downsides of: >> > 1) grows the debug info (it is already huge; who is counting?) >> > 2) reveals file system layout in debug info (privacy?) >> > 3) does it inhibit debugging files from other people's machines >> or does gdb dir still work? >> > >> > but definitely makes for a more pleasant debugging experience >> when >> > debugging stuff you have built yourself. >> > >> > The linear searching to see if a name has been allocated a >> number yet >> > will obviously slow way down due to a large increase in common >> prefixes, >> > but that should be a hash table anyway. Linear search is lame. >> > (or a trie, but working from the ends of the strings, minus the >> last one or few >> > characters, due to common prefixes as well as common suffixes) >> > >> > Note that both m3front and m3cc changes are needed as m3front >> has >> paths >> > relative to the current working directory or such. >> > >> > For most packages, you can get by without the m3front change >> and >> just prepend >> > "../src/" to the path in m3cc, but that doesn't work for >> hierarchical packages >> > such as libm3 and m3core which I am debugging. >> ------------------------------------------------------------------------ >> Need to know the score, the latest news, or you need your Hotmail?- >> get your "fix". Check it out. > > > > -- > ------------------------------------------------------------- > 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 Feb 28 21:11:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 21:11:07 +0100 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Message-ID: <20080228211107.vkj5tlcs08c4csss@mail.elegosoft.com> Quoting Jay : >> You cannot expect to be better than the underlying platform :-/ > Cygwin is much slower than the underying platform I believe.. Thast's what I meant. You (CM3) cannot be better than Cygwin on NT386GNU. It's a problem of the Cygwin platform (not of CM3 and not of 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 wagner at elegosoft.com Thu Feb 28 21:18:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 21:18:36 +0100 Subject: [M3devel] multiple pkg roots? In-Reply-To: <1204222970.13580.62.camel@hias.m3w.org> References: <1204222970.13580.62.camel@hias.m3w.org> Message-ID: <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> Quoting Dragi?a Duri? : > Is it possible to ship to more than one location, and/or have system > find package imported in list of locations, instead from one location? This is currently only possible with overrides. CM3 does not support multiple package pools, though that would be a nice extension. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu Feb 28 21:42:13 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 21:42:13 +0100 Subject: [M3devel] multiple pkg roots? In-Reply-To: <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> References: <1204222970.13580.62.camel@hias.m3w.org> <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> Message-ID: <1204231333.13580.69.camel@hias.m3w.org> And, if overriden, then we cannot ship that package... I am looking at M3Build.m3 now... One of spaghetti pieces of cm3 :) dd On Thu, 2008-02-28 at 21:18 +0100, Olaf Wagner wrote: > Quoting Dragi?a Duri? : > > > Is it possible to ship to more than one location, and/or have system > > find package imported in list of locations, instead from one location? > > This is currently only possible with overrides. CM3 does not support > multiple package pools, though that would be a nice extension. > > Olaf -- Dragi?a Duri? From rodney.bates at wichita.edu Fri Feb 29 00:54:32 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 17:54:32 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204226001.13580.64.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> Message-ID: <47C749B8.1060906@wichita.edu> I have a long list of things to fix/improve in m3gdb, which I periodically work on. But it builds and runs for LINUXLIBC6 and does lots of useful thins. Just minutes ago, I happened to build it on a newly-installed Ubuntu, on LINUXLIBC6 and it is working as expected. For Ubuntu, I had to install package libncurses5-dev (apt-get install libncurses-dev) to get it to build. do-cm3-std.sh did not build it. I will check in my do-cm3-m3gdb.sh, which is a convenient way to build it. There is currently an annoying new bug in displaying subrange values in cm3-compiled code, that often incorrectly thinks the type's range is empty, and then complains the value is out of range. It does give you the numeric value anyway. I have added lots of new stuff to the expression evaluation in the past few years. You can type unmangled, qualified names of variables and procedures, execute procedure and method calls, etc. Much of this is summarized in the various checkin comments, which is, of course, not very handy as a way to read up. It has been on my list to write something up on this. As for other platforms, I don't have any around, and I'm not aware of anybody trying it. Dragi?a Duri? wrote: > I am probably missing it, and few of my last runs had some problems... > So - what is current state of m3gdb on LINUXLIBC6? Working? Under > fixing? > > TIA, > dd -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 01:25:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 18:25:36 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204226001.13580.64.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> Message-ID: <47C75100.9040004@wichita.edu> P.S. m3gdb dynamically detects and adapts to cm3 or pm3- compiled code (or src or ezm3). Also the integrated back end or the gcc-derived back ends. In cm3, code needs to be compiled with -gstabs+. Dragi?a Duri? wrote: > I am probably missing it, and few of my last runs had some problems... > So - what is current state of m3gdb on LINUXLIBC6? Working? Under > fixing? > > TIA, > dd -- ------------------------------------------------------------- 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 Fri Feb 29 01:19:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 Feb 2008 01:19:36 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C749B8.1060906@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> Message-ID: <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> Quoting "Rodney M. Bates" : > As for other platforms, I don't have any around, and I'm not aware of anybody > trying it. It compiles without problems on FreeBSD 6.3 and works as long as programs are linked with libthr.so (not with libpthread.so). I haven't used it much yet, and some things seemed to be strange; thread stack switching or viewing didn't work at all. If you want to try anything on FreeBSD, let me know, I can provide a remote login. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 29 02:01:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:01:02 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad? What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume. As is setting them by full name PosixProcess__WaitProcess. That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number. Do people do that? I guess the gui wrappers do, but I assume that'd still work. ? Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching? Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience. Gdb automatically shows me the source as I step, instead of just file name and line number. cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom: void assert_failed(const char* condition, const char* file, unsigned line); #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also: printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths. I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:36:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:36:08 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:35:25 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:35:25 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 04:01:42 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 22:01:42 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> On Feb 28, 2008, at 8:01 PM, Jay wrote: > Are you all serious? Telling the debugger the full path to source > files via the debuginfo is bad? > What are the issues? I want to know so that when I use the switch I > know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb > a few weeks ago). > > What I could imagine is affected is setting them by file and line > number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a > full path? Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not. > Gdb doesn't have any fuzzy matching? Not sure. > Maybe in gcc I can give multiple file names? Again, not sure. > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so > by default gdb was showing hardly anything at all, quite poor. I > admit, I'm at the start of the learning curve on gdb. I had to look > to find the dir command. I had to look to find display/x $pc. To use > the dir command, I have to constantly switch my slashes, since I get > the paths from dir /s/b. I use gdb under emacs... if the emacs bindings continue to work then OK, but if not then problems. > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned > line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. I look forward to Rodney's input since he has most experience with m3gdb and its expectations, and moreover with the current behavior of gdb for other languages. > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So > any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, > then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current > working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your > Hotmail?- > > >> get your "fix". Check it out. > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 04:02:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 22:02:23 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <4A155BD0-9DBF-4F25-96D5-C4AE16F61F62@cs.purdue.edu> Before we decide a switch is needed, can anyone tell me what gcc does by default for C? Does gcc have a switch already? On Feb 28, 2008, at 8:36 PM, Jay wrote: > If this must be a switch, what should the default be? > I suspect the default should be full paths. > > And then, should there be switches for each of: > debuginfo > assertions > webinfo > > "assertions" actually use the Modula-3 equivalent of __FILE__. > And so, what this should perhaps looks like is, using bogus Cish > names, > __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/ > unix/usomething.m3) > __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix > \fooposix.m3) > __LEAF_FILE__ (e.g. fooposix.m3) > > or maybe just the first two, and maybe the one that exists today > retains its meaning and a new "full file" is introduced. And then > folks can use it if they wish, and assertion maybe honors a switch. > > I hate to make everything TOO flexible and configurable though. It > can get confusing, and the underutilized options may get undertested > (but better now with increasing automated testing). > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; rodney.bates at wichita.edu > Date: Fri, 29 Feb 2008 01:01:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > Are you all serious? Telling the debugger the full path to source > files via the debuginfo is bad? > What are the issues? I want to know so that when I use the switch I > know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb > a few weeks ago). > > What I could imagine is affected is setting them by file and line > number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a > full path? > Gdb doesn't have any fuzzy matching? > Maybe in gcc I can give multiple file names? > > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so > by default gdb was showing hardly anything at all, quite poor. I > admit, I'm at the start of the learning curve on gdb. I had to look > to find the dir command. I had to look to find display/x $pc. To use > the dir command, I have to constantly switch my slashes, since I get > the paths from dir /s/b. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned > line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So > any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, > then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current > working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your > Hotmail?- > > >> get your "fix". Check it out. > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 04:52:50 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 03:52:50 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> Message-ID: > ...debugger itself with the debug info as it was. It already> > contained one copy of the full path to the source file in each > > object file, though I don't know of a place the debugger uses this now.btw, I don't think this part is true. I don't believe the object files contain full source paths anywhere. But oops, I admit I didn't open the .ms or .mo files and double check that. However, "the way it works", where "it" is the little bit of code I looked at, is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that path was passed in to gcc. My experience with gdb strongly suggests that this sort of path is the only one in the debug info. I will check more stuff tonight, the behavior of __FILE__, the behavior of gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the behavior of emacs+gdb (yet another learning curve..man, being low in the callstack requires familiarity with everyone's workflow above you..) I wonder as well if a list of directories can be put in the debug info. You know, partly as a size optimization, and possibly to address these issues. (of course the size optimization could be independently implemented) When I stepping, I don't really need gdb to show me the full path, that is often but not always noise, I just need it to know the full path so it can show the source. As things were, gdb wouldn't find source without dir commands. Command line debuggers are quite daunting. I don't know if it is worthwhile to strive to reduce the fear and pain they cause, or just suck it all up because you'll hardly make much of a dent anyway. ? - Jay CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to source files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500 On Feb 28, 2008, at 8:01 PM, Jay wrote: Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path? Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not. Gdb doesn't have any fuzzy matching? Not sure. Maybe in gcc I can give multiple file names? Again, not sure. This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I use gdb under emacs... if the emacs bindings continue to work then OK, but if not then problems. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. I look forward to Rodney's input since he has most experience with m3gdb and its expectations, and moreover with the current behavior of gdb for other languages. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Feb 29 10:39:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 29 Feb 2008 01:39:43 -0800 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: Your message of "Fri, 29 Feb 2008 03:52:50 GMT." Message-ID: <200802290939.m1T9dhnk058397@camembert.async.caltech.edu> I'm pretty sure I've seen full paths in ASSERT failures, using, perhaps, ezm3? It didn't cause any gdb problems (I use the old m3gdb a lot). Mika Jay writes: >--_93b0d79c-137f-47e2-9518-78e460fd7ea0_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> ...debugger itself with the debug info as it was. It already> > contained= > one copy of the full path to the source file in each > > object file, thou= >gh I don't know of a place the debugger uses this now.btw, I don't think th= >is part is true. >I don't believe the object files contain full source paths anywhere. >But oops, I admit I didn't open the .ms or .mo files and double check that. >However, "the way it works", where "it" is the little bit of code I looked = >at, >is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that >path was passed in to gcc. >=20 >My experience with gdb strongly suggests that this sort of path is the only >one in the debug info. >=20 >I will check more stuff tonight, the behavior of __FILE__, the behavior of = >gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the = >behavior of emacs+gdb (yet another learning curve..man, being low in the ca= >llstack requires familiarity with everyone's workflow above you..) >=20 >I wonder as well if a list of directories can be put in the debug info. >You know, partly as a size optimization, and possibly to address these issu= >es. > (of course the size optimization could be independently implemented) >When I stepping, I don't really need gdb to show me the full path, that is = >often but not always noise, I just need it to know the full path so it can = >show the source. As things were, gdb wouldn't find source without dir comma= >nds. >=20 >Command line debuggers are quite daunting. >I don't know if it is worthwhile to strive to reduce the fear and pain they= > cause, or just suck it all up because you'll hardly make much of a dent an= >yway. ? >=20 > - Jay > > >CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.= >eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to sour= >ce files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500 > > >On Feb 28, 2008, at 8:01 PM, Jay wrote: > > >Are you all serious? Telling the debugger the full path to source files via= > the debuginfo is bad?What are the issues? I want to know so that when I us= >e the switch I know what trouble I'm bringing myself. Setting breakpoints i= >n "modules", as .dll/.so files, is unaffected I presume.As is setting them = >by full name PosixProcess__WaitProcess.That is what I "always" do ("always"= > as in, I just started using gdb a few weeks ago). What I could imagine is = >affected is setting them by file and line number.Do people do that? I guess= > the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I = >should try out xcode and ddd and such? Do people say like break foo.c:#123?= > And now I've made them use a full path? > >Yes, I do this all the time...via the emacs keybindings -- not sure if full= > paths would break things or not. > >Gdb doesn't have any fuzzy matching? >Not sure. > > >Maybe in gcc I can give multiple file names? > >Again, not sure. > >This really greatly improves the out-of-the-box minimally configured debugg= >ing experience.Gdb automatically shows me the source as I step, instead of = >just file name and line number.cdb/windbg at least show disassembly by defa= >ult, but gdb doesn't, so by default gdb was showing hardly anything at all,= > quite poor. I admit, I'm at the start of the learning curve on gdb. I had = >to look to find the dir command. I had to look to find display/x $pc. To us= >e the dir command, I have to constantly switch my slashes, since I get the = >paths from dir /s/b. > >I use gdb under emacs... if the emacs bindings continue to work then OK, b= >ut if not then problems. > >I will make it a switch in cm3 and cm3cg if it is really a problem. In C it= > is a common idiom:void assert_failed(const char* condition, const char* fi= >le, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FI= >LE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the = >compiler on the command line", or "full path", depending on implementation.= > Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems li= >ke basic correctness to me, to give a debugger full paths.I'm quite surpris= >ed by the pushback. > >I look forward to Rodney's input since he has most experience with m3gdb an= >d its expectations, and moreover with the current behavior of gdb for other= > languages. > >Assertions I think should also be "fixed" further. And I suspect "webinfo" = >but that could wait until Reactor is available.. - Jay > >> From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 = >Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] = >FW: put full paths to source files in debug info]> > I concur with Rodney o= >n this. There are deeper issues here than > simply avoiding the need to use= > dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> >= > I don't understand what the need for these paths is. In every > > complete= >> > program, all the interfaces and all the modules must have unique > > si= >mple> > names, otherwise code could not refer to them. With the filename > = >> matchup> > rules, this should make all the simple file names unique too. = >So any> > debug commands should never need a path. And using simple names >= > > avoids> > the problems of moving compiled code.> >> > Is it more output = >from the debugger you want? If so, this could no > > doubt> > be done by th= >e debugger itself with the debug info as it was. It > > already> > containe= >d one copy of the full path to the source file in each > > object file,> > = >though I don't know of a place the debugger uses this now.> >> > Yes, I kno= >w the filename/modulename rules don't actually apply for > > modules,> > bu= >t not following them is a bad practice. I've been around that > > block man= >y> > times with Ada, and believe me, it's a nightmare. Furthermore, then > = >> you> > wouldn't be able to name things in the debugger as > > ModuleName.= >VarOrProcInModule,> > This construct does not exist in code but is very use= >ful in > > debugging, especially> > when InterfaceName/ModuleName is not on= >e-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wr= >ote:> >> truncated again! and possibly misformated..> >> > >> -------------= >-----------------------------------------------------------> >> From: jayk1= >23 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full path= >s to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> = >>> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> thi= >s also, but not fully.> >> Before you would have gotten:> >> ***> >> *** ru= >ntime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3"= >, line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *= >** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m= >3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable= > Modula-3 > >> library> >> call is) should be moved up to m3front to addres= >s these, and the> >> parse.c change undone.> >> As well, I believe resolvin= >g symlinks is happening too but > >> that> >> wasn't the point, so somethin= >g instead of realpath might be> >> preferable. Like, just see if the string= > starts ".\" or "..\", it> >> will almost always start "..\", and if so, pr= .. From rodney.bates at wichita.edu Fri Feb 29 17:43:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 10:43:35 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> Message-ID: <47C83637.6010602@wichita.edu> Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> As for other platforms, I don't have any around, and I'm not aware of >> anybody >> trying it. > > > It compiles without problems on FreeBSD 6.3 and works as long as > programs are linked with libthr.so (not with libpthread.so). Any more information on what the difference in these libraries is? > I haven't used it much yet, and some things seemed to be strange; > thread stack switching or viewing didn't work at all. m3gdb needs work on threads. I have never done anything on it. Unless Tony did some when he was working on it several years ago, I think it is pretty much as it came from SRC, and that was fairly primitive. Plus, the new pthreads implementation is not supported. Once I glanced at the code and it looked immediately like what was there would not work at all. This has been on my list a while. > > If you want to try anything on FreeBSD, let me know, I can provide > a remote login. Yes, that would be helpful. > > Olaf -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:11:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:11:35 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <47C83CC7.9060905@wichita.edu> Jay wrote: > Are you all serious? Telling the debugger the full path to source files > via the debuginfo is bad? Below. > What are the issues? I want to know so that when I use the switch I know > what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. In m3gdb, you can also say PosixProcess.WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb a > few weeks ago). > > What I could imagine is affected is setting them by file and line number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a full path? Yes. PosixProcess.m3:123 is the normal way. Since source file simple names are unique, this is enough in Modula-3. I suppose in C, if somebody actually had >1 source file with the same simple name, something messier would be needed, but normally, break Foo.c:123 is the way to do it. Likewise, before your change to debug info, output from (m3)gdb showing where something is stopped uses source file simple names and line numbers too. > Gdb doesn't have any fuzzy matching? > Maybe in gcc I can give multiple file names? > > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just file > name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so by > default gdb was showing hardly anything at all, quite poor. I admit, I'm > at the start of the learning curve on gdb. I had to look to find the dir > command. I had to look to find display/x $pc. To use the dir command, I > have to constantly switch my slashes, since I get the paths from dir /s/b. The paths to source are used in (m3)gdb only to display a portion of actual source code, not to identify file/line# places. For the former function only, (m3)gdb has to have full paths, and they must be as they may have changed since things were compiled/linked. I put -d command line options for all my source file paths (which do the same thing as dir gdb commands) in a startup file for any project that gets significant work. I do agree, it would be nice for a quick jump into a debugger, not to have to do this. It could only work, of course, if the source files are where they were at the time of compilation. The way to do this is for gdb to try the path from the object module, after normal use of dir/-d paths have failed. Since we can't change gdb, this would only be in m3gdb. On big advantage of this would be that it would work when one needs to debug right into the runtime system, as I do somewhat regularly. That requires several additional paths that one would not ordinarily have specified. The way we are installing Modula-3 now, it is a pretty safe bet that, if the source exists at all, then it where it was when the runtime system was compiled. (Well, copies of the interfaces do get placed in the install directory, but I'm not sure m3gdb ever displays non-executable code, which is all that interfaces have.) You have convinced me to add this to my list. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) > : (void)0) > We don't have anything like __FILE__ and __LINE__ in Modula-3. I have a largish program full of assertions with it's own coded assertion handling, including recoverable (in a sense, roll back to a consistent state) assertion failures. It could use something like this. But it also seems pretty hackish to me too. > __FILE__ can vary between "the parameter to the compiler on the command > line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a debugger > full paths. People can and often do move executables to different machines and also sometimes move source trees around on the original machine. Using simple file names within an executable (of which there is always exactly one) is invariant to all this, and a lot shorter to type/read. > I'm quite surprised by the pushback. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your Hotmail?- > > >> get your "fix". Check it out. > > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your Hotmail?-get > your "fix". Check it out. -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:18:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:18:15 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204267238.13580.75.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <1204267238.13580.75.camel@hias.m3w.org> Message-ID: <47C83E57.4060202@wichita.edu> Hmm. I'm not sure what happens here. It will be the same as the stock gdb (6.4) from which m3gdb is derived. I think it has a way of getting debug info from separate files, but I have never used this. The m3gdb changes to gdb don't do anything about this. I have, a few times, at intervals of two or three years, forward ported (back ported? what does one call this?) the Modula-3 changes into newer gdb releases. If there is something in the newest gdb that is really needed, I can do that again, although when I last thought about it (6.7), there was some target gdb had dropped that we still have in cm3. Dragi?a Duri? wrote: > During RPM building process, rpmbuild strips debug info and packs it > separatelly. Is m3gbd recognizing this situation and using debug info > in, for example: > > /usr/lib/debug/usr/local/cm3/bin/m3gdb.debug > /usr/lib/debug/usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/parseparams/LINUXLIBC6/libm3parseparams.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/set/LINUXLIBC6/libset.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/tcp/LINUXLIBC6/libm3tcp.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/tempfiles/LINUXLIBC6/libTempFiles.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/udp/LINUXLIBC6/libUDP.so.5.debug > > TIA, > dd > > On Thu, 2008-02-28 at 17:54 -0600, Rodney M. Bates wrote: > >>I have a long list of things to fix/improve in m3gdb, which I periodically >>work on. But it builds and runs for LINUXLIBC6 and does lots of useful thins. >> >>Just minutes ago, I happened to build it on a newly-installed Ubuntu, on >>LINUXLIBC6 and it is working as expected. For Ubuntu, I had to install >>package libncurses5-dev (apt-get install libncurses-dev) to get it to >>build. do-cm3-std.sh did not build it. I will check in my do-cm3-m3gdb.sh, >>which is a convenient way to build it. >> >>There is currently an annoying new bug in displaying subrange values in >>cm3-compiled code, that often incorrectly thinks the type's range is empty, >>and then complains the value is out of range. It does give you the numeric >>value anyway. >> >>I have added lots of new stuff to the expression evaluation in the past few >>years. You can type unmangled, qualified names of variables and procedures, >>execute procedure and method calls, etc. Much of this is summarized in the >>various checkin comments, which is, of course, not very handy as a way to >>read up. It has been on my list to write something up on this. >> >>As for other platforms, I don't have any around, and I'm not aware of anybody >>trying it. >> >>Dragi?a Duri? wrote: >> >>>I am probably missing it, and few of my last runs had some problems... >>>So - what is current state of m3gdb on LINUXLIBC6? Working? Under >>>fixing? >>> >>>TIA, >>>dd >> -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:32:49 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:32:49 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> Message-ID: <47C841C1.3090202@wichita.edu> Jay wrote: > > ...debugger itself with the debug info as it was. It already > > > contained one copy of the full path to the source file in each > > > object file, though I don't know of a place the debugger uses this now. > > btw, I don't think this part is true. > I don't believe the object files contain full source paths anywhere. > But oops, I admit I didn't open the .ms or .mo files and double check that. > However, "the way it works", where "it" is the little bit of code I > looked at, > is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that > path was passed in to gcc. > > My experience with gdb strongly suggests that this sort of path is the only > one in the debug info. Evidence: ----------------------------------------------------------------------------------------------- [rodney at selkirk LINUXLIBC6]$ objdump -G Sets.mo | more Sets.mo: file format elf32-i386 Contents of .stab section: Symnum n_type n_othr n_desc n_value n_strx String -1 HdrSym 0 839 00001db3 1 0 SO 0 0 00000000 9 /home/rodney/proj/util/m3/ordsets/LINUXLIBC6/ 1 SO 0 0 00000000 55 Sets.mc 2 OPT 0 0 00000000 63 gcc2_compiled. ... A bunch of irrelevant type definitions deleted ......... 3 LSYM 0 0 00000000 78 26 SOL 0 0 00000000 1353 Sets.m3 ----------------------------------------------------------------------------------------------- This is from an earlier compiler, before your change. Your change shows up in the last line, in front of Sets.m3. The path in the separate SO line is to the compiled object file, not the source. For Modula-3, getting the source file is usually trivial, although not always, especially the RTS. When changing m3gdb to use this after normal dir/-d paths have failed, I would consider changing cm3 to emit a 3rd SO line with the source path, *IF* this didn't choke stock gdb, which I doubt it would. However m3gdb works on code compiled by all the compilers, including older versions of cm3, so perhaps searching below ../src would be needed anyway. > > I will check more stuff tonight, the behavior of __FILE__, the behavior > of gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and > MAYBE the behavior of emacs+gdb (yet another learning curve..man, being > low in the callstack requires familiarity with everyone's workflow above > you..) > > I wonder as well if a list of directories can be put in the debug info. > You know, partly as a size optimization, and possibly to address these > issues. > (of course the size optimization could be independently implemented) > When I stepping, I don't really need gdb to show me the full path, that > is often but not always noise, I just need it to know the full path so > it can show the source. As things were, gdb wouldn't find source without > dir commands. > > Command line debuggers are quite daunting. > I don't know if it is worthwhile to strive to reduce the fear and pain > they cause, or just suck it all up because you'll hardly make much of a > dent anyway. ? > > - Jay > > ------------------------------------------------------------------------ > CC: rodney.bates at wichita.edu; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] FW: put full paths to source files in debug info] > Date: Thu, 28 Feb 2008 22:01:42 -0500 > > On Feb 28, 2008, at 8:01 PM, Jay wrote: > > Are you all serious? Telling the debugger the full path to > source files via the debuginfo is bad? > What are the issues? I want to know so that when I use the > switch I know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is > unaffected I presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using > gdb a few weeks ago). > > What I could imagine is affected is setting them by file and > line number. > Do people do that? I guess the gui wrappers do, but I assume > that'd still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use > a full path? > > > Yes, I do this all the time...via the emacs keybindings -- not sure > if full paths would break things or not. > > Gdb doesn't have any fuzzy matching? > > > Not sure. > > Maybe in gcc I can give multiple file names? > > > Again, not sure. > > This really greatly improves the out-of-the-box minimally > configured debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb > doesn't, so by default gdb was showing hardly anything at all, > quite poor. I admit, I'm at the start of the learning curve on > gdb. I had to look to find the dir command. I had to look to > find display/x $pc. To use the dir command, I have to constantly > switch my slashes, since I get the paths from dir /s/b. > > > I use gdb under emacs... if the emacs bindings continue to work > then OK, but if not then problems. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, > unsigned line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. > > > I look forward to Rodney's input since he has most experience with > m3gdb and its expectations, and moreover with the current behavior > of gdb for other languages. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > ------------------------------------------------------------------------ > >> From: hosking at cs.purdue.edu >> To: rodney.bates at wichita.edu >> Date: Thu, 28 Feb 2008 14:12:33 -0500 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: put full paths to source files in > debug info] >> >> I concur with Rodney on this. There are deeper issues here than >> simply avoiding the need to use dir in gdb. >> >> On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: >> >> > >> > I don't understand what the need for these paths is. In every >> > complete >> > program, all the interfaces and all the modules must have > unique >> > simple >> > names, otherwise code could not refer to them. With the > filename >> > matchup >> > rules, this should make all the simple file names unique > too. So any >> > debug commands should never need a path. And using simple names >> > avoids >> > the problems of moving compiled code. >> > >> > Is it more output from the debugger you want? If so, this > could no >> > doubt >> > be done by the debugger itself with the debug info as it > was. It >> > already >> > contained one copy of the full path to the source file in each >> > object file, >> > though I don't know of a place the debugger uses this now. >> > >> > Yes, I know the filename/modulename rules don't actually > apply for >> > modules, >> > but not following them is a bad practice. I've been around that >> > block many >> > times with Ada, and believe me, it's a nightmare. > Furthermore, then >> > you >> > wouldn't be able to name things in the debugger as >> > ModuleName.VarOrProcInModule, >> > This construct does not exist in code but is very useful in >> > debugging, especially >> > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module >> > exports >1 >> > interface, etc. >> > >> > Jay wrote: >> >> truncated again! and possibly misformated.. >> >> >> >> > ------------------------------------------------------------------------ >> >> From: jayk123 at hotmail.com >> >> To: m3devel at elegosoft.com >> >> Subject: RE: put full paths to source files in debug info >> >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> >> pps: "webinfo" (Reactor?) and assertion failures are > affected by >> >> this also, but not fully. >> >> Before you would have gotten: >> >> *** >> >> *** runtime error: >> >> *** <*ASSERT*> failed. >> >> *** file "WaitProcessCygwin.m3", line 16 >> >> *** >> >> but now you get: >> >> *** >> >> *** runtime error: >> >> *** <*ASSERT*> failed. >> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> >> *** >> >> I'd say the realpath call (or whatever the portable Modula-3 >> >> library >> >> call is) should be moved up to m3front to address these, > and the >> >> parse.c change undone. >> >> As well, I believe resolving symlinks is happening too but >> >> that >> >> wasn't the point, so something instead of realpath might be >> >> preferable. Like, just see if the string starts ".\" or > "..\", it >> >> will almost always start "..\", and if so, prepend current > working >> >> directory and then workout the dots. >> >> It may also be reasonable to provide paths to the compiler >> >> to remove >> >> from the starts of paths, which would likely address the > symlink >> >> issue, since they are more likely to be nearer the start of > the >> >> path >> >> than the middle or end. As well as partly the >> >> privacy/size/same-across-machines issues. >> >> In any case, I think this easy small change is already very >> >> useful >> >> progress. Or does everyone else just fill up .gdbinit with dir >> >> commands? It seems to me that it shouldn't even that > difficult, >> >> even >> >> if it isn't very difficult. >> >> Agreed? >> >> - Jay >> >> >> >> > ------------------------------------------------------------------------ >> >> From: jayk123 at hotmail.com >> >> To: m3devel at elegosoft.com >> >> Subject: re: put full paths to source files in debug info >> >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> >> ps: does anyone care that binaries built from different cvs >> >> checkouts, but otherwise identical source, will no longer > match, >> >> unless perhaps they are "stripped"? >> >> If so, or if any of the other issues bug people, or any other >> >> problem is brought up or discovered, this can be made a command >> >> line option. I will always turn it on. :) >> >> - Jay >> >> >> >> > ------------------------------------------------------------------------ >> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> >> > To: m3commit at elegosoft.com >> >> > From: jkrell at elego.de >> >> > Subject: [M3commit] CVS Update: cm3 >> >> > >> >> > CVSROOT: /usr/cvs >> >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> >> > >> >> > Modified files: >> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> >> > Scanner.m3 >> >> > >> >> > Log message: >> >> > put full paths to source files in debug info >> >> > >> >> > This has the minor downsides of: >> >> > 1) grows the debug info (it is already huge; who is > counting?) >> >> > 2) reveals file system layout in debug info (privacy?) >> >> > 3) does it inhibit debugging files from other people's > machines >> >> or does gdb dir still work? >> >> > >> >> > but definitely makes for a more pleasant debugging > experience >> >> when >> >> > debugging stuff you have built yourself. >> >> > >> >> > The linear searching to see if a name has been allocated a >> >> number yet >> >> > will obviously slow way down due to a large increase in > common >> >> prefixes, >> >> > but that should be a hash table anyway. Linear search is > lame. >> >> > (or a trie, but working from the ends of the strings, > minus the >> >> last one or few >> >> > characters, due to common prefixes as well as common > suffixes) >> >> > >> >> > Note that both m3front and m3cc changes are needed as > m3front >> >> has >> >> paths >> >> > relative to the current working directory or such. >> >> > >> >> > For most packages, you can get by without the m3front change >> >> and >> >> just prepend >> >> > "../src/" to the path in m3cc, but that doesn't work for >> >> hierarchical packages >> >> > such as libm3 and m3core which I am debugging. >> >> > ------------------------------------------------------------------------ >> >> Need to know the score, the latest news, or you need your > Hotmail?- >> >> get your "fix". Check it out. > > >> > >> > >> > -- >> > ------------------------------------------------------------- >> > 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 >> > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". Check it out. > > > > > ------------------------------------------------------------------------ > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > -- ------------------------------------------------------------- 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 dragisha at m3w.org Fri Feb 29 18:20:35 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 29 Feb 2008 18:20:35 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C83637.6010602@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> Message-ID: <1204305635.13580.82.camel@hias.m3w.org> On Fri, 2008-02-29 at 10:43 -0600, Rodney M. Bates wrote: > m3gdb needs work on threads. I have never done anything on it. > Unless Tony did some when he was working on it several years ago, > I think it is pretty much as it came from SRC, and that was fairly > primitive. Plus, the new pthreads implementation is not supported. > Once I glanced at the code and it looked immediately like what was > there would not work at all. This has been on my list a while. "Stock" gdb does support pthreads. Is that not enough for m3gdb? As for former M3 threads, msgdb had patches to go through thread lists, and many things more. As current implementation has no such kind of control over threads, I see no point in pursuing anything similar to what was before. > > > > > If you want to try anything on FreeBSD, let me know, I can provide > > a remote login. > > Yes, that would be helpful. > > > > > Olaf > -- Dragi?a Duri? From hosking at cs.purdue.edu Fri Feb 29 18:46:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 12:46:07 -0500 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C83637.6010602@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> Message-ID: m3gdb should probably avoid any specific reliance on the particular threads implementation. If using pthreads, then gdb already has support for that (I frequently debug threads issues for CM3 using the regular gdb without any problems). If using SIGVTALRM threads then I would suggest that users will need to be familiar with the thread scheduling points that it uses (triggered by SIGVTALRM, and implemented by Thread.Transfer). Since there is no way for m3gdb to "switch" contexts for SIGVTALRM threads then it really might as well be agnostic about threads generally. In summary, there should not be need for *special* support for threads in m3gdb. 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 Feb 29, 2008, at 11:43 AM, Rodney M. Bates wrote: > > > Olaf Wagner wrote: >> Quoting "Rodney M. Bates" : >>> As for other platforms, I don't have any around, and I'm not aware >>> of anybody >>> trying it. >> It compiles without problems on FreeBSD 6.3 and works as long as >> programs are linked with libthr.so (not with libpthread.so). > > Any more information on what the difference in these libraries is? > >> I haven't used it much yet, and some things seemed to be strange; >> thread stack switching or viewing didn't work at all. > > m3gdb needs work on threads. I have never done anything on it. > Unless Tony did some when he was working on it several years ago, > I think it is pretty much as it came from SRC, and that was fairly > primitive. Plus, the new pthreads implementation is not supported. > Once I glanced at the code and it looked immediately like what was > there would not work at all. This has been on my list a while. > >> If you want to try anything on FreeBSD, let me know, I can provide >> a remote login. > > Yes, that would be helpful. > >> Olaf > > -- > ------------------------------------------------------------- > 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 Fri Feb 29 18:46:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 12:46:49 -0500 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204305635.13580.82.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> Message-ID: <37E0E1B4-710C-4A1D-B42F-380E14451D5F@cs.purdue.edu> Precisely! 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 Feb 29, 2008, at 12:20 PM, Dragi?a Duri? wrote: > On Fri, 2008-02-29 at 10:43 -0600, Rodney M. Bates wrote: >> m3gdb needs work on threads. I have never done anything on it. >> Unless Tony did some when he was working on it several years ago, >> I think it is pretty much as it came from SRC, and that was fairly >> primitive. Plus, the new pthreads implementation is not supported. >> Once I glanced at the code and it looked immediately like what was >> there would not work at all. This has been on my list a while. > > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > > As for former M3 threads, msgdb had patches to go through thread > lists, and many things more. As current implementation has no such > kind > of control over threads, I see no point in pursuing anything similar > to > what was before. > >> >>> >>> If you want to try anything on FreeBSD, let me know, I can provide >>> a remote login. >> >> Yes, that would be helpful. >> >>> >>> Olaf >> > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 19:27:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 13:27:51 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <47C83CC7.9060905@wichita.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <47C83CC7.9060905@wichita.edu> Message-ID: On Feb 29, 2008, at 12:11 PM, Rodney M. Bates wrote: > > > Jay wrote: >> Are you all serious? Telling the debugger the full path to source >> files via the debuginfo is bad? > > Below. > >> What are the issues? I want to know so that when I use the switch I >> know what trouble I'm bringing myself. >> Setting breakpoints in "modules", as .dll/.so files, is unaffected >> I presume. >> As is setting them by full name PosixProcess__WaitProcess. > > In m3gdb, you can also say PosixProcess.WaitProcess. > >> That is what I "always" do ("always" as in, I just started using >> gdb a few weeks ago). >> What I could imagine is affected is setting them by file and line >> number. >> Do people do that? I guess the gui wrappers do, but I assume that'd >> still work. ? >> Maybe it depends. I should try out xcode and ddd and such? >> Do people say like break foo.c:#123? And now I've made them use a >> full path? > > Yes. PosixProcess.m3:123 is the normal way. Since source file > simple names > are unique, this is enough in Modula-3. I suppose in C, if somebody > actually > had >1 source file with the same simple name, something messier > would be > needed, but normally, break Foo.c:123 is the way to do it. > > Likewise, before your change to debug info, output from (m3)gdb > showing where > something is stopped uses source file simple names and line numbers > too. > >> Gdb doesn't have any fuzzy matching? >> Maybe in gcc I can give multiple file names? >> This really greatly improves the out-of-the-box minimally >> configured debugging experience. >> Gdb automatically shows me the source as I step, instead of just >> file name and line number. >> cdb/windbg at least show disassembly by default, but gdb doesn't, >> so by default gdb was showing hardly anything at all, quite poor. I >> admit, I'm at the start of the learning curve on gdb. I had to look >> to find the dir command. I had to look to find display/x $pc. To >> use the dir command, I have to constantly switch my slashes, since >> I get the paths from dir /s/b. > > The paths to source are used in (m3)gdb only to display a portion of > actual > source code, not to identify file/line# places. For the former > function only, > (m3)gdb has to have full paths, and they must be as they may have > changed since > things were compiled/linked. I put -d command line options for all my > source file paths (which do the same thing as dir gdb commands) in a > startup > file for any project that gets significant work. > > I do agree, it would be nice for a quick jump into a debugger, not > to have > to do this. It could only work, of course, if the source files are > where > they were at the time of compilation. The way to do this is for gdb > to > try the path from the object module, after normal use of dir/-d > paths have > failed. Since we can't change gdb, this would only be in m3gdb. Indeed! Given that cm3 compiles in one location and ships to another it is important that full paths *not* be used I suspect. That way, one can have users of installed packages debug against their source as necessary. > On big advantage of this would be that it would work when one needs to > debug right into the runtime system, as I do somewhat regularly. That > requires several additional paths that one would not ordinarily have > specified. The way we are installing Modula-3 now, it is a pretty > safe > bet that, if the source exists at all, then it where it was when the > runtime system was compiled. > > (Well, copies of the interfaces do get placed in the install > directory, but > I'm not sure m3gdb ever displays non-executable code, which is all > that interfaces have.) > > You have convinced me to add this to my list. > >> I will make it a switch in cm3 and cm3cg if it is really a problem. >> In C it is a common idiom: >> void assert_failed(const char* condition, const char* file, >> unsigned line); >> #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, >> __LINE__) : (void)0) >> > > We don't have anything like __FILE__ and __LINE__ in Modula-3. I > have a > largish program full of assertions with it's own coded assertion > handling, > including recoverable (in a sense, roll back to a consistent state) > assertion > failures. It could use something like this. But it also seems > pretty hackish > to me too. Sure we do: Compiler.ThisLine() Compiler.ThisFile() > > >> __FILE__ can vary between "the parameter to the compiler on the >> command line", or "full path", depending on implementation. >> Also: >> printf("foo is %d in %s\n", foo, __FILE__). >> This really just seems like basic correctness to me, to give a >> debugger full paths. > > People can and often do move executables to different machines and > also > sometimes move source trees around on the original machine. Using > simple > file names within an executable (of which there is always exactly one) > is invariant to all this, and a lot shorter to type/read. Agreed. > > >> I'm quite surprised by the pushback. >> Assertions I think should also be "fixed" further. And I suspect >> "webinfo" but that could wait until Reactor is available.. >> - Jay >> ------------------------------------------------------------------------ >> > From: hosking at cs.purdue.edu >> > To: rodney.bates at wichita.edu >> > Date: Thu, 28 Feb 2008 14:12:33 -0500 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] FW: put full paths to source files in >> debug info] >> > >> > I concur with Rodney on this. There are deeper issues here than >> > simply avoiding the need to use dir in gdb. >> > >> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: >> > >> > > >> > > I don't understand what the need for these paths is. In every >> > > complete >> > > program, all the interfaces and all the modules must have unique >> > > simple >> > > names, otherwise code could not refer to them. With the filename >> > > matchup >> > > rules, this should make all the simple file names unique too. >> So any >> > > debug commands should never need a path. And using simple names >> > > avoids >> > > the problems of moving compiled code. >> > > >> > > Is it more output from the debugger you want? If so, this could >> no >> > > doubt >> > > be done by the debugger itself with the debug info as it was. It >> > > already >> > > contained one copy of the full path to the source file in each >> > > object file, >> > > though I don't know of a place the debugger uses this now. >> > > >> > > Yes, I know the filename/modulename rules don't actually apply >> for >> > > modules, >> > > but not following them is a bad practice. I've been around that >> > > block many >> > > times with Ada, and believe me, it's a nightmare. Furthermore, >> then >> > > you >> > > wouldn't be able to name things in the debugger as >> > > ModuleName.VarOrProcInModule, >> > > This construct does not exist in code but is very useful in >> > > debugging, especially >> > > when InterfaceName/ModuleName is not one-to-one, e.g. when a >> module >> > > exports >1 >> > > interface, etc. >> > > >> > > Jay wrote: >> > >> truncated again! and possibly misformated.. >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> From: jayk123 at hotmail.com >> > >> To: m3devel at elegosoft.com >> > >> Subject: RE: put full paths to source files in debug info >> > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> > >> pps: "webinfo" (Reactor?) and assertion failures are affected by >> > >> this also, but not fully. >> > >> Before you would have gotten: >> > >> *** >> > >> *** runtime error: >> > >> *** <*ASSERT*> failed. >> > >> *** file "WaitProcessCygwin.m3", line 16 >> > >> *** >> > >> but now you get: >> > >> *** >> > >> *** runtime error: >> > >> *** <*ASSERT*> failed. >> > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> > >> *** >> > >> I'd say the realpath call (or whatever the portable Modula-3 >> > >> library >> > >> call is) should be moved up to m3front to address these, and the >> > >> parse.c change undone. >> > >> As well, I believe resolving symlinks is happening too but >> > >> that >> > >> wasn't the point, so something instead of realpath might be >> > >> preferable. Like, just see if the string starts ".\" or "..\", >> it >> > >> will almost always start "..\", and if so, prepend current >> working >> > >> directory and then workout the dots. >> > >> It may also be reasonable to provide paths to the compiler >> > >> to remove >> > >> from the starts of paths, which would likely address the symlink >> > >> issue, since they are more likely to be nearer the start of the >> > >> path >> > >> than the middle or end. As well as partly the >> > >> privacy/size/same-across-machines issues. >> > >> In any case, I think this easy small change is already very >> > >> useful >> > >> progress. Or does everyone else just fill up .gdbinit with dir >> > >> commands? It seems to me that it shouldn't even that difficult, >> > >> even >> > >> if it isn't very difficult. >> > >> Agreed? >> > >> - Jay >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> From: jayk123 at hotmail.com >> > >> To: m3devel at elegosoft.com >> > >> Subject: re: put full paths to source files in debug info >> > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> > >> ps: does anyone care that binaries built from different cvs >> > >> checkouts, but otherwise identical source, will no longer match, >> > >> unless perhaps they are "stripped"? >> > >> If so, or if any of the other issues bug people, or any other >> > >> problem is brought up or discovered, this can be made a command >> > >> line option. I will always turn it on. :) >> > >> - Jay >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> > >> > To: m3commit at elegosoft.com >> > >> > From: jkrell at elego.de >> > >> > Subject: [M3commit] CVS Update: cm3 >> > >> > >> > >> > CVSROOT: /usr/cvs >> > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> > >> > >> > >> > Modified files: >> > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> > >> > Scanner.m3 >> > >> > >> > >> > Log message: >> > >> > put full paths to source files in debug info >> > >> > >> > >> > This has the minor downsides of: >> > >> > 1) grows the debug info (it is already huge; who is counting?) >> > >> > 2) reveals file system layout in debug info (privacy?) >> > >> > 3) does it inhibit debugging files from other people's >> machines >> > >> or does gdb dir still work? >> > >> > >> > >> > but definitely makes for a more pleasant debugging experience >> > >> when >> > >> > debugging stuff you have built yourself. >> > >> > >> > >> > The linear searching to see if a name has been allocated a >> > >> number yet >> > >> > will obviously slow way down due to a large increase in common >> > >> prefixes, >> > >> > but that should be a hash table anyway. Linear search is lame. >> > >> > (or a trie, but working from the ends of the strings, minus >> the >> > >> last one or few >> > >> > characters, due to common prefixes as well as common suffixes) >> > >> > >> > >> > Note that both m3front and m3cc changes are needed as m3front >> > >> has >> > >> paths >> > >> > relative to the current working directory or such. >> > >> > >> > >> > For most packages, you can get by without the m3front change >> > >> and >> > >> just prepend >> > >> > "../src/" to the path in m3cc, but that doesn't work for >> > >> hierarchical packages >> > >> > such as libm3 and m3core which I am debugging. >> > >> >> ------------------------------------------------------------------------ >> > >> Need to know the score, the latest news, or you need your >> Hotmail?- >> > >> get your "fix". Check it out. > > >> > >> > > >> > > -- >> > > ------------------------------------------------------------- >> > > 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 >> > >> ------------------------------------------------------------------------ >> Need to know the score, the latest news, or you need your Hotmail?- >> get your "fix". Check it out. > > > > -- > ------------------------------------------------------------- > 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 rodney.bates at wichita.edu Fri Feb 29 22:09:47 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 15:09:47 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204305635.13580.82.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> Message-ID: <47C8749B.6070101@wichita.edu> Do you know if this pthread support was in by gdb 6.4? Dragi?a Duri? wrote: > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 22:18:53 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 15:18:53 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <47C83CC7.9060905@wichita.edu> Message-ID: <47C876BD.10003@wichita.edu> Tony Hosking wrote: >> We don't have anything like __FILE__ and __LINE__ in Modula-3. I have a >> largish program full of assertions with it's own coded assertion >> handling, >> including recoverable (in a sense, roll back to a consistent state) >> assertion >> failures. It could use something like this. But it also seems >> pretty hackish >> to me too. > > > Sure we do: > > Compiler.ThisLine() > Compiler.ThisFile() > Thank you. I didn't know about these. -- ------------------------------------------------------------- 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 mika at async.caltech.edu Fri Feb 29 22:19:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 29 Feb 2008 13:19:43 -0800 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: Your message of "Fri, 29 Feb 2008 11:11:35 CST." <47C83CC7.9060905@wichita.edu> Message-ID: <200802292119.m1TLJhcB080697@camembert.async.caltech.edu> "Rodney M. Bates" writes: ... >People can and often do move executables to different machines and also >sometimes move source trees around on the original machine. Using simple >file names within an executable (of which there is always exactly one) >is invariant to all this, and a lot shorter to type/read. ... Arbitrary paths are also not trustworthy on many Unix systems that run automounters. The path you get from getcwd is likely not to be permanently accessible on those. (You access the files via a different path.) Mika From hendrik at topoi.pooq.com Fri Feb 29 23:41:26 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 29 Feb 2008 17:41:26 -0500 Subject: [M3devel] random-acces I/O Message-ID: <20080229224126.GA21397@topoi.pooq.com> I need to do direct-access I/O from a Modula 3 program with a file format that is externally specified. It is necessary to both read and write in random fashion during a run of the program, prefereably without having to close or open the file each time. I expect the answers to the following questions are "Yes", but I'd appreciate confirmation: ? If I have a File.T (obtained from FS.OpenFile) can I have both a Rd.T and a Wr.T active on it simultaeously? ? Will things written using the Wr.T be immediately available for reading with the Rd.T, with no buffereing problems? ? Are there methods for locking the file -- or portions of it -- against simutaneous access by other programs, including ones written in other languages? -- hendrik From dragisha at m3w.org Fri Feb 29 23:09:11 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 29 Feb 2008 23:09:11 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C8749B.6070101@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> <47C8749B.6070101@wichita.edu> Message-ID: <1204322951.13580.87.camel@hias.m3w.org> I think it's in since 6.0 at least. And maybe even as war as 4.17. I am using, when debugging threads, only gdb commands. And it, sort of, works... I still have to try debugger seriously. dd On Fri, 2008-02-29 at 15:09 -0600, Rodney M. Bates wrote: > Do you know if this pthread support was in by gdb 6.4? > > Dragi?a Duri? wrote: > > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > > -- Dragi?a Duri? From jayk123 at hotmail.com Thu Feb 7 05:08:04 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 07 Feb 2008 04:08:04 -0000 Subject: [M3devel] Latest parse.c In-Reply-To: References: Message-ID: >> I don't think it "quits" for us, but worth the printf'ing and such. >> like Sleep(int,record,int,record); >> I wouldn't be surprised if you get @16, but I'm placing no bets here. :) confirmed. Wish I had more to report by now.. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Feb 12 04:29:30 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 12 Feb 2008 03:29:30 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> Message-ID: <47B1168F.8020302@wichita.edu> It sounds like all that Mac OS X needs is for _all_ types in an entire program to use the liberal packing rules. Have I understood correctly? I would have no grief over that. Darko wrote: > The liberalised alignment rules are required for the native Mac OS X > API and should stay. You cannot use that API without them. I think the > pragma is not required and can be removed. I agree with all the points > you make. The effect of the modified alignment rules it to allow > *packed* structures to have members aligned on byte boundaries. This > has the effect of packing the fields in the tightest arrangement > allowed by the platform. This might affect performance, but if the user > is concerned about this they should specify field bit sizes that > deliver improved performance. I don't see a need to specify this on a > structure level, for the reasons you give and because the difference > isn't significant enough in the case of packed structures and their > physical layout and restrictions are platform dependent anyway. > > I might also add that the alignment code is currently broken on > I386_DARWIN. > > - Darko > > > On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > >> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >> being used anywhere? >> >> It is not documented in pragmas.html. The compiler front end appears >> to accept it. (In fact, Decls.m3 contains constants that suggest >> limitations on what declarations the pragma can appear on, but these >> are not actually enforced.) It liberalizes the alignment rules, >> generally allowing scalars to start on any byte boundary. >> >> Pickles have to be able to reconstruct the layout of types as the >> compiler would have done it for a machine (on which a now-being-read >> pickle was written) with different word size and alignment properties. >> Currently, pickles are completely unaware of lazy alignment. It >> would have to be encoded in type descriptions generated by the compiler >> using TipeDesc and read by pickles using RTTipe. >> >> Most troubling to me is what looks like a linguistic Pandora's box. >> The pragma can be associated with any constant, variable, or type >> _declaration_ (not type definition), with the result that different >> values of the same type can actually be different in their alignment >> rules and thus their layout. Similarly for different identifiers >> equated to the same type. Although the effects of this could possibly >> be hidden from the programmer in purely safe code, not so with unsafe >> code. I haven't thoroughly thought this through, but seems to me to >> really fly in the face of the whole typing philosophy of the language. >> >> For example, if pickles were to read in an object value, and there >> were >1 variants of the object's type in the reading program, differing >> only in the alignment rules, how would it decide which one to build? >> In fact, ignoring pickles altogether and just looking at a single >> program, >> if the object's type doesn't actually uniquely give its memory layout, >> how can it be accessed correctly? >> >> Additionally, a quick look at the compiler suggests it won't generate >> correct code for whole record assignment when the LHS and RHS are the >> same type but have different alignment characteristics. >> >> The more I think about it, it seems the only workable possibilities are: >> >> 1) Require the pragma to be associated only with a type _definition_ >> not a >> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make this a >> property of the type that propagates to all names for the type and >> all variables, constants, etc. Also, this would make this property >> a part of the type signature that pickles uses when reading, -OR- >> >> 2) Forget it altogether. >> >> What do people think? >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 darko at darko.org Wed Feb 13 03:20:56 2008 From: darko at darko.org (Darko) Date: Wed, 13 Feb 2008 02:20:56 -0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: <53857.165.228.199.218.1202868771.squirrel@webmail.darko.org> Possibly, but it's a worthy goal. M3 should be deployable on any platform. Too much of the discussion lately seems to be tieing the language to particular platforms, we should be pushing the other way. I'm insterested in working toward a distribution which has no platform APIs, only native M3 interfaces with native strings, traced references only and range checked and enumaterated everything. We should be looking to absact away C interfaces at a low level, not permeate upwards. > My principle concern is that once we provide C APIs then C will > permeate the M3 space more pervasively (both apps and libraries). > What happens when I want to bring up a system where there is no > C?!?! Consider the SPIN OS perhaps... > > Maybe I am just being overly fusty... > > On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > >> What we _maybe_ can do... is to make some special, preprocessable >> source >> form, which some quake command can parse into multiple files in their >> folders. And these file can be compiled later...Kind of how generic >> works. >> >> But, as current system works, and it does it very well, and as only >> case >> where we really need this is Windows... most Unices being or becoming >> POSIX... I don't see it's smart to spend resources on becoming more >> C... >> Esp when "founding fathers" made it so good and so much non-C :). >> >> If we really need to make some approach to "their world", it's much >> better to work on interoperability issues and thus cement our >> first-class-citizen language status even more. >> >> dd >> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >>> Jay: >>> >>> My understanding of Modula-3 is that rather than cluttering up the >>> source code with a bunch of preprocessor directives to deal with the >>> various changes needed by various platforms, a separate source >>> file is >>> used for platforms whose implementation must diverge. The m3makefile >>> is used to control the selection of these platform sources at build >>> time. I like this approach much better. >>> >>> Regards, >>> Randy >>> >>>>>> Jay 2/11/2008 8:21 PM >>> >>> So I have NOT thought this through. >>> >>> I wonder if "preprocessing" dependent only on "target" is a good >>> idea. >>> >>> Something like either the ability to prefix pragmas with a target, or >>> an "iftarget" and "ifnottarget" pragma. >>> >>> Something like so: >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> It's a small can of worms. >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an >>> interface/module). >>> >>> What about IF_OSTYPE? >>> What about expressions? >>> IF_TARGET NT386 OR NTAMD64 >>> >>> IF_TARGET STARTS(NT) >>> >>> etc. >>> >>> I don't really have enough interest here to work through this, just >>> sending out the bait... >>> >>> Obviously this was triggered by my happening into the odbc directory >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >>> conventions with a target. >>> >>> This reminds me of an important point here however -- nobody else is >>> going to make the mistake of ever having multiple calling >>> conventions. >>> Therefore the generality of prefixing WINAPI with NT386: is useless. >>> Unless Mac68K support is added. >>> >>> And here is some rationale even. The PC and Mac evolved from "small" >>> systems, where assembly programming was common, more people knew more >>> lower level details and playing games with calling conventions was >>> something anyone could do. Most other current systems are rooted in C >>> programming. Working in C, calling conventions are generally in a >>> hidden layer below what anyone thinks about. Therefore, the smaller >>> number of capable people working at that level have the good sense to >>> only have one calling convention. No more systems will evolve from >>> "small", at least not without having observed this history. >>> Therefore, >>> there will no longer be multiple calling conventions. >>> >>> That is my theory at least. >>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >>> only x86 >> -- >> Dragi??a Duri?? > > From dabenavidesd at yahoo.es Thu Feb 14 05:56:08 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 14 Feb 2008 04:56:08 -0000 Subject: [M3devel] Modula-3 discussions In-Reply-To: Message-ID: <855460.51998.qm@web27107.mail.ukl.yahoo.com> Hi all: I think that all humans sometimes make mistakes (specially me :), is up to us try to solve them in the best way (I also think there is only one way). I think I don't have enough patience to read the multiple emails Jay write some inspired days (believe me I sometimes don't like to see so many mails from the list even if they are written by Jay or not), however if I am considered and fraternal with all of you I must read it and if I can make some input/comment is a very good think to do it, I think they are very convenient, so for the purpose of a better arguing why we don't try to stay calm and try to understand that the comments of other people are valuable as our opinions are, and learn something important: hear other's opinions. I understand that in a free software project there is always a leader, a head or a principal, maybe this is clear to some of you, but also there are others whom want to make inputs to the development of the project. So two discussions are very clear in the m3devel lasts posts: some of us like more C, some of us like more other languages and some of us like Modula3 as it is, but that doesn't imply that we must change our way of thinking just because we don't agree with some other opinions and the way of continue cm3 development (but we also can question ourselves). We do use the mail for several good purposes but sometimes we forget a important issue: we are saying things to rest of the world that has access to this list, we are trying to get people more involved with the language environment and we don't want to loose users or developers, so it just doesn't matter if we agree with all the opinions of them (I remember one user in the m3devel list some time ago wrote that he has some code and he want to publish it, but I can't fin id it at the moment). I would like to know if It is very rare to try to migrate some part of the programming languages discussion on comp.lang.modula3 and the rest of the most related with cm3 development in m3devel list. Also if we have enough users to try to organize a Modula-3 user group meeting . For instance I know recent research work made by Laszlo Boeszoermenyi, I also can say that in our University (http://www.unal.edu.co) have been deloped in the last 7 years two projects with Modula-3 (one of control and automatization and one of cgi programming), also it was dictated several courses using Modula-3 (there is a set of slides that it's not published yet based on Laszlo's book, I hope this can be give to community if it is important). Why don't try to spend some time making an index of such academic or research and commercial projects, people and institutions towards the benefit of the language developers and it's users. It existed on Michael Dagenais old m3 site a list of modula-3 contributors and enthusiasts: http://web.archive.org/web/20020326115358/http://m3.polymtl.ca/m3/faq/who/ I don't know if it exists on elego source tree tough Also update the acknowledgements of this url: http://modula3.elegosoft.com/pm3/pkg/intro/src/ack.html Well, I almost finishing this "inspired" email, I hope you enjoyed as me :) Thanks you for all the discussion :) and work. --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 15 04:46:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 03:46:43 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> Message-ID: <47B50EDF.8060807@wichita.edu> 1) RTPacking.T and needs to have a separate size for LONGINT, (which can vary independently of the size of INTEGER). 2) Variable length values of subrange bounds found in type descriptions (in TipeDesc.i3) can now have values beyond what the native word size can represent. 3) RTType.Kind.Longint (which I presume you, Tony, added recently) is not handled by Pickles. I have done some coding on this, but have been interrupted. Tony Hosking wrote: > Why is LONGINT for pickles not yet supported? > -- ------------------------------------------------------------- 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 ronny.forberger at elegosoft.com Mon Feb 18 09:37:59 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Mon, 18 Feb 2008 08:37:59 -0000 Subject: [M3devel] Just a mailing list test Message-ID: <20080218093759.x4hxlv3m884wo0s8@mail.elegosoft.com> Please ignore. Ronny -- 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 mika at async.caltech.edu Tue Feb 19 00:09:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 23:09:47 -0000 Subject: [M3devel] code submission In-Reply-To: Your message of "Mon, 18 Feb 2008 19:50:20 GMT." Message-ID: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> That's right, that's approximately what it does. More succinctly, like this :) t.tab : REF ARRAY OF RECORD value : Value.T; next : INTEGER := 0 END; PROCEDURE Get(t : T; READONLY k : ARRAY OF Key.T) : Value.T = VAR p := 0; BEGIN FOR i := FIRST(k) TO LAST(k) DO WITH next = t.tab[p][k[i]].next DO IF next = 0 THEN RETURN t.defValue (* not found *) ELSE p := next END END END; RETURN t.tab[p][k[LAST(k)]].value END Get; Knuth section 6.3 talks about it; he claims the word is based on "information reTRIEval". Tries can be faster than hash methods when most of the words are not to be found in the dictionary, and you can tell by reading just one or two characters that you don't have that word. Parsing a data file in the way what I am doing is an example: I am only interested in a very small subset of the lines. (The application is, given the complete data set for the Toronto Stock Exchange for a month, extract certain records pertaining to a small subset of stock tickers.) Of course, which tickers it is changes all the time, so you can't really compile in a special-case switch statement either. In my application, using the standard Modula-3 TEXT and Text.Hash, plus Text<>Tbl was many times slower than AWK. The trie code is quite a bit faster (completely limited by disk speed). Mika Jay writes: >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >aka "prefix tree" >if I want to recognize the strings, foo, food, fudge, and bar >look at the first character > if it is 'b', go ahead and compare to bar (or the tail to "ar") > if it is 'f' > look at the second character > if it is 'u', go ahead and compare to "fudge" (or the tail to "dge") > if it 'o' > compare the third character > and so on >=20 >Whether or not the data "stops" at unique prefixes is an implementation det= >ail. >If it does, the leaves can contain the entire string or just the tail. >I've fiddled with generating large nested switch statements from a list of = >strings. >I noticed there are many optimizations you can make. >Of course, first you check the length. >Then, really, instead of progressing from left to right, you can pick out c= >haracters with a higher switching factor. >For example if I have the strings foof and food, just look at the last char= >acter. >=20 >As well a hash based algorithm is probably best. >Precompute the hashes of all the strings. >Sor them. >Hash your input string. >Binary search for the hash. >And the compare for an exact match. >=20 >If you are going to do the final compare anyway, then you are going to touc= >h the whole string anyway, you might as well hash it and do a binary search= > I think. Make sure the hash function is fast of course, and not "perfect". >=20 > - Jay >=20 > > > >> Date: Mon, 18 Feb 2008 20:35:36 +0100> From: wagner at elegosoft.com> To: mi= >ka at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cod= >e submission> > Quoting Mika Nystrom :> > > Hello e= >veryone,> >> > I was looking at some code I've written and realized that I = >have a> > very small piece of tested code that may be of interest to other>= > > Modula-3 users. It's a generic "trie" that I coded a few years> > ago. D= >oes anyone have an opinion on adding it to cm3? Where, if so?> >> > http://= >www.async.caltech.edu/~mika/trie/> >> > It's useful for parsing; if you're = >parsing a language with longish> > keywords it is many times faster to use = >this structure and ARRAY> > OF CHAR than using the standard hash tables wit= >h TEXTs. (I developed> > it to parse an old "punch-card", i.e., 80-characte= >r fixed-width> > records, format for financial data.)> > Of course we could= > add this as a small package to m3-libs, or> even to libm3 (it looks rather= > small).> > I hate to sound so uneducated, but what exactly does `trie' sta= >nd for?> It's not contained in my favourite online dictionary either.> > Ol= >af> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-A= >llee 25 / Geb=E4ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mo= >bile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | = >Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgerich= >t Charlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >aka "prefix tree"

>if I want to recognize the strings, foo, food, fudge, and bar
>look at the first character
>  if it is 'b', go ahead and compare to bar (or the tail to "ar")
>  if it is 'f'
>   look at the second character
>     if it is 'u', go ahead and compare to "fudge" (or = >the tail to "dge")
>     if it 'o'
>        compare the third character
>        and so on
> 
>Whether or not the data "stops" at unique prefixes is an implementation det= >ail.
>If it does, the leaves can contain the entire string or just the tail.
>
I've fiddled with generating large nested switch statements from a list= > of strings.
>I noticed there are many optimizations you can make.
>Of course, first you check the length.
>Then, really, instead of progressing from left to right, you can pick out c= >haracters with a higher switching factor.
>For example if I have the strings foof and food, just look at the last char= >acter.
> 
>As well a hash based algorithm is probably best.
>Precompute the hashes of all the strings.
>Sor them.
>Hash your input string.
>Binary search for the hash.
>And the compare for an exact match.
> 
>If you are going to do the final compare anyway, then you are going to touc= >h the whole string anyway, you might as well hash it and do a binary search= > I think. Make sure the hash function is fast of course, and not "perfect".= >
> 
> - Jay
> 
> >
>
>> Date: Mon, 18 Feb 2008 20:35:36 +0100
> From: wagner at elegosoft.c= >om
> To: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
= >> Subject: Re: [M3devel] code submission
>
> Quoting Mika N= >ystrom <mika at async.caltech.edu>:
>
> > Hello everyone= >,
> >
> > I was looking at some code I've written and rea= >lized that I have a
> > very small piece of tested code that may b= >e of interest to other
> > Modula-3 users. It's a generic "trie" t= >hat I coded a few years
> > ago. Does anyone have an opinion on ad= >ding it to cm3? Where, if so?
> >
> > http://www.async.ca= >ltech.edu/~mika/trie/
> >
> > It's useful for parsing; if= > you're parsing a language with longish
> > keywords it is many ti= >mes faster to use this structure and ARRAY
> > OF CHAR than using = >the standard hash tables with TEXTs. (I developed
> > it to parse = >an old "punch-card", i.e., 80-character fixed-width
> > records, f= >ormat for financial data.)
>
> Of course we could add this as = >a small package to m3-libs, or
> even to libm3 (it looks rather small= >).
>
> I hate to sound so uneducated, but what exactly does `t= >rie' stand for?
> It's not contained in my favourite online dictionar= >y either.
>
> Olaf
>
>
>
> --
&= >gt; Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee= > 25 / Geb=E4ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96= > mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegos= >oft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelreg= >ister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>= >


Connect and share in new ways with Windows Live. ef=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelif= >e_012008' target=3D'_new'>Get it now! >= > >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_-- From wagner at elegosoft.com Tue Feb 19 00:30:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 23:30:50 -0000 Subject: [M3devel] code submission In-Reply-To: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> References: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> Message-ID: <20080219003049.nmeda2ky8880ksss@mail.elegosoft.com> Quoting Mika Nystrom : > Knuth section 6.3 talks about it; he claims the word is based on > "information reTRIEval". Tries can be faster than hash methods > when most of the words are not to be found in the dictionary, and > you can tell by reading just one or two characters that you don't > have that word. Parsing a data file in the way what I am doing is > an example: I am only interested in a very small subset of the > lines. (The application is, given the complete data set for the > Toronto Stock Exchange for a month, extract certain records pertaining > to a small subset of stock tickers.) Of course, which tickers it > is changes all the time, so you can't really compile in a special-case > switch statement either. > In my application, using the standard Modula-3 TEXT and Text.Hash, > plus Text<>Tbl was many times slower than AWK. The trie code is quite > a bit faster (completely limited by disk speed). OK, thanks for the explanations. I should have a look at the old standard books more often. I know prefix trees, but had never heard the term `trie'. I think we should definitely add it. I'm still not sure if it should go better into its own package or into the generics part of libm3. What do the others 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 darko at darko.org Tue Feb 19 01:32:07 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 00:32:07 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> We seem to be going through these same point several times. I'm not sure what the difficulty is, I'm just repeating myself. Keep in mind this applies *only* to packed structures, ie BIT FOR or bit fields. The change I put in libralised the *M3* alignment rules so that BITS FOR fields in structures would align on byte boundries if possible instead of restricting them to word alignment generally. GCC happily generates code for this. There may be restrictions in GCC's C as to how you can arrange bit fields but I don't see what they have to do with M3. This is absolutely essentail for using the native APIs on Mac OS X and its removal would make M3 pointless for use on the Mac, at least more me. This should be the default behviour. If you are using BITS FOR it's becuase you want to arrange the fields in a record in particular way. Why then arbitrarliy pad out the fields? If performance is an issue, the user should be using appropriate field bit sizes. The implementation rule for BITS FOR in M3 is implementation dependent, there are no language issues. The LAZYALIGN pragma (that is, the prgama itself) is something Olaf created and had nothing to do with me. I diagreed with it and never used it in the version of the compiler I ran. I support its removal. > On Feb 18, 2008, at 3:01 PM, Darko wrote: > >> The alignment behaviour is absolutely crucial to programming >> natively in Mac OS X and should be kept. I have a great need for it. >> >> The PRGAMA is of no use and can be removed. >> >> Does anyone have any objections to making this alignment behaviour >> standard? > > What do you mean make LAZYALIGN standard? Why wouldn't we go with > the standard gcc-backend alignment? Perhaps I don't understand what > it is you are doing or trying to do. Again, please remind me what it > is that LAZYALIGN does and why it is needed. > >> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >> >>> Can someone remind me again why we need LAZYALIGN? I concur with >>> Randy that if it is rarely used and moreso breaks things I would >>> argue to abandon it. >>> >>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>> >>>> I use pickles extensively and they are used also by network objects. >>>> I've never used LAZYALIGN. >>>> My vote is that we don't break something (pickles/netobj) to add >>>> support for something that is rarely used. >>>> Regards, >>>> Randy >>>> >>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>> PM >>> >>>> I'll put it in comments in the code. I am sure I can fix it to >>>> handle LAZYALIGN too, just not sure whether I can do it without >>>> requiring existing pickle files to be regenerated and/or existing >>>> code that reads/writes pickles to need recompilation. >>>> >>>> Anybody on this list who has code that might be affected if pickles >>>> or compiled code were invalidated by a change? >>>> >>>> I do propose we change the way of telling the compiler to do >>>> LAZYALIGN so that it is a property of a type and affects all >>>> variables of that type. >>>> >>>> Olaf Wagner wrote: >>>> > Perhaps we should check-in this description somewhere near the >>>> > actual code? Or is there enough documentation already? >>>> > >>>> > Olaf >>>> > >>>> > PS: Based on your description, I'd say we should abandon >>>> LAZYALIGN. >>>> > Or at least put a big sticker on that it will break pickles. >>>> > >>>> > Quoting "Rodney M. Bates" : >>>> > >>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>> BITSIZE, >>>> >> etc. only works for getting object layouts as on the machine >>>> executing >>>> >> the code, which is all that is needed when writing a pickle. >>>> >> >>>> >> When reading, Pickle code needs to know the layouts of a type >>>> both as >>>> >> it is on the reading machine and as it was on the machine that >>>> wrote >>>> >> the pickle. The type description that the compiler generates is >>>> >> excerpted and contains no field displacements, just lists of >>>> field >>>> >> types (which are either recursive type descriptions or builtin >>>> types). >>>> >> So it is independent of word sizes, etc. >>>> >> >>>> >> Pickles regenerates the displacements using the few target >>>> machine >>>> >> characteristics in a RTPacking.T It traverses a type >>>> description and >>>> >> simultaneously computes two sets of field displacements, both >>>> as they >>>> >> are on the reading machine and on the writing machine. For >>>> the latter, >>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>> stored in the >>>> >> header of the pickle file. For the former, it's gotten by >>>> techniques >>>> >> like >>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>> m3core, and >>>> >> called by Pickle code. >>>> >> >>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>> layout >>>> >> behavior. There is no shared code. Making it common would >>>> involve >>>> >> quite a bit of rework, as the two use substantially different >>>> data >>>> >> structure and code organization. It will be obvious what kind >>>> of bit >>>> >> damage could occur if the two algorithms didn't agree. >>>> >> >>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>> comparing the >>>> >> field displacement computations in RTTipe and in the >>>> compiler. The >>>> >> former is oblivious to LAZYALIGN. >>>> >> >>>> >> Note that all this is required even without any packing of >>>> small fields >>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>> on a >>>> >> 32-bit machine and unpickled on a 64. >>>> >> >>>> >> Tony Hosking wrote: >>>> >> >>>> >>> Rodney, >>>> >>> >>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>> >>> would have thought all packing is done on word-sized units >>>> anyway. >>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>> figure >>>> >>> out what to do presumably no differently from the way >>>> INTEGER is >>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>> >>> something? >>>> >>> >>>> >>> -- Tony >>>> >>> >>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>> >>> >>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>> help with? >>>> >>>> >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>> >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> >>>>> (which can vary independently of the size of INTEGER). >>>> >>>>> 2) Variable length values of subrange bounds found in type >>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> >>>>> what the native word size can represent. >>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>> recently) >>>> >>>>> is not handled by Pickles. >>>> >>>>> >>>> >>>>> I have done some coding on this, but have been interrupted. >>>> >>>>> >>>> >>>>> Tony Hosking wrote: >>>> >>>>> >>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> ------------------------------------------------------------- >>>> >>>>> 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 >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >> >>>> >> -- >>>> >> ------------------------------------------------------------- >>>> >> 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 >>>> > >>>> > >>>> > >>>> > >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 rodney.bates at wichita.edu Tue Feb 19 03:00:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 19 Feb 2008 02:00:36 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B9644F.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> Message-ID: <47BA3AC5.40907@wichita.edu> Just to clarify: I don't believe anything existing has to break. The worst scenario I can see is that you would have to either simultaneously upgrade the compiler, libm3, and libm3core (or else none of these) before recompiling & linking any code that reads or writes pickles. If libm3 and libm3core are dynamically linked in at runtime, you would have to recompile with an upgraded compiler at the same time as installing the upgraded dynamic libraries. Existing pickle files would not change. Also, mixtures of programs thus recompiled & linked and programs not recompiled/linked could exchange pickle files. Anything that (un)pickles records or objects that are LAZYALIGN would need the upgrade to work, but such programs are already broken. Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add support > for something that is rarely used. > Regards, > Randy > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Sat Feb 23 04:43:22 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 23 Feb 2008 03:43:22 -0000 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> Message-ID: <47BF99F0.9050402@wichita.edu> Yes, most of this is done in RTTipe. I tend to speak sloppily about this as "pickles", which are, I believe, the only client code of RTTipe in the CM3 distribution. Darko wrote: > Then I assume RTTipe needs to be fixed, and pickles and the alignment > are ok. > >-- ------------------------------------------------------------- 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 Sun Feb 24 16:11:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:11:44 +0100 Subject: [M3devel] Pathname.T extensions, was: Re: exposing both path name types? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: <20080224161144.zgi5zplzk8sgcc8s@mail.elegosoft.com> Actually I think it's a good idea to provide platform-specific interfaces for pathnames in libm3. This way programs can use the common pathname abstraction in general and special features of target specific pathnames if they need to. Especially when programming in a mixed Windows/POSIX environment this will help to keep things simpler. I'd suggest something like this: extends Pathname.T <---- PathnamePosix.T <---- PathnameWindows/NTFS.T <---- PathnameCygwin.T <---- [PathnameDos/FAT.T] (probably no need currently) <---- [PathnameOS2.T] (probably no need currently) (An alternative hinted at above would be to name interfaces after the actual file systems; there could be different implementations for UFS, ZFS, NTFS, FAT, HFS, SMBFS, etc. then. This may go too far though.) Pathname.T should keep all the abstractions that are curently there; nothing must be changed syntactically or semantically. It may be extended by an equal predicate (and thus abstract from case differences if needed) and perhaps more useful methods (arcSeparatorChar/Text(), hasPlatformSpecificRoot(), ...). PathnameWindows.T could extend the functionality by methods for handling of drives and UNC syntax; PathnameCygwin.T could contain support for /cygdrive/... conversion etc. All Pathname modules should only depend on pure TEXT functions (i.e. not platform specific library calls etc.). All derived types should implement initialization methods for conversions: initFromPosix( PathnamePosix.T ) initFromWindows( PathnameWindows.T ) initFromCygwin( PathnameCygwin.T ) Specialized applications like the CM3 builder which are platform specific to a certain extend could then use standard function calls to convert between different pathname representations as needed. Again, I think we should first exactly define the interfaces, and then provide some unit tests. I'll see if I can find some old tests as a start. BTW, the quake functions that were part of the original proposal I sent to the list are not implemented in quake because they were not really thought over well; if there are implementations of these in M3 (sysutils), these are just historic relicts and probably not very general and powerful. What do the others think? Olaf Quoting Jay : > What is the idiom for this: > > Currently: > There is Pathname.i3. > PathnamePosix EXPORTS Pathname > PathnameWin32 EXPORTS Pathname > You can only have one in a link. > > It would seem possibly useful to have: > Pathname.i3 unchanged > PathnamePosix.i3 identical to Pathname.i3 (some what to avoid the > duplication?) > PathnameWin32.i3 identical to Pathname.i3 (ditto) > > On Posix targets: > PathnameWin32.m3 exports just PathnameWin32 > PathnamePosix exports both PathnamePosix and Pathname > > On Windows targets: > PathnamePosix exports just PathnamePosix > PathnameWin32 exports both PathnameWin32 and Pathname > > That is Pathname.Foo resolves statically at compile time to the > target-specific library. > PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. > > These modules each import nothing, except Text. They do all their > string manipulation themselves. > > Olaf's recent Quake extensions document but don't implement > pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( > pn ) --> text > As long as pn is a fullpath, these are easy, I just wrote up > prototypes, haven't compiled them. > > I think these functions might suggest doing what I'm asking about as > well, maybe. > Or maybe you'd just convert and then never pick back apart. > > I have sleazed by for now by using subst_text / to \ and setting up > NTFS junctions. > In this way, I can cross build NT386 <=> NT386GNU either host, either target. > Had I not done anything, the linker interprets > /cygdrive/c/foo/bar.lib as a command switch and says it doesn't > understand it. > Not a big deal, but I think there might be some easy progress here. > > This is not just about Pathname. > > It is also about File. > Even though NT386GNU File is FilePosix, it would be useful to allow > the serial package to use FileWin32 instead. > But FilePosix and FileWin32 both reveal the same types. > It'd be nice if they could expose FilePosix.T and FileWin32.T and > then only one of them reveal File.T = FilePosix.T or File.T = > FileWin32.T, something like that. > > > - Jay > _________________________________________________________________ > Climb to the top of the charts! Play the word scramble challenge > with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Feb 24 16:32:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:32:05 +0100 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> Message-ID: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Quoting Jay : > Oh darn, inevitably that is not my final answer.. > more like attached.. Jay, the files seem to work OK on my FreeBSD system. But the tinderbox tests on birch and new have failed, in spite of my CVS revert; so please don't commit anything until I have found out what is wrong. It may take some time, because I'm expecting guests soon and won't be able to do much until tomorrow evening. Olaf > - Jay > > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000 > > > Olaf can you try the attached? Thanks, - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Feb 27 03:49:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 21:49:50 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> Message-ID: On Feb 26, 2008, at 6:46 PM, Jay wrote: > Tony, what about the need to copy? The inability to iterate through > characters without a function call per character? I guess though, > from what you pointed out, a read only direct pointer is viable. And > that removes the 256 character stack usage -- which is a bit piggy > as it is. So then..I guess the next step in some compromise here is > that it should perhaps be viable to get a read only pointer to a > string (maybe already the case), compute the required size of the > new one (follows naturally), and then be able to split up allocation > and filling in of a string, a function to allocate and get a direct > pointer, then fill in your data, then "seal" the text making it read > only. And I guess really you can just carefully use the "subversive" > method here -- up to you to not pass the "unsealed" text off to > anyone else until you are done writing to it. Have you looked at TextConv.i3? Not sure if that has some of what you are needing. > Then just to deal with the varying representation but as I was > suggesting, maybe that can be forced somehow. > Maybe creation can specify an encoding, or the "get buffer" function > could -- though ideally there is just one, not two. > > The stack vs. heap behavior is also not ideal in that it's nice for > the performance of something to scale linearly with input, not > suddenly slow way down when data exceeds some arbitrary threshold. > Granted, a lot of code just starts failing, so merely slowing down > is "progress". As well, eventually you end up swapping to disk, if > you don't first run out of address space, so there will be limits at > which things slow down or fail, just that they ought to be fairly > large. Why do you think that heap allocation is slow in general? > I also rather hoped/assumed that compile time text constants were > formed constant-ly by the compiler, that the compiler knows their > runtime layout. I realize the division of labor between compiler and > runtime can be made at varying points, with varying resulting > flexibility, but also varying resulting efficiency. Compile-time literals *are* formed constantly by the compiler. They are TextLiteral.T. > > > - Jay > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Tue, 26 Feb 2008 17:43:17 -0500 > Subject: Re: [M3devel] text inefficiency? good mutable string type? > arrays? > > I suppose the question here is how often you exceed the 256- > character stack-allocated buffer size? If not often then > occasionally allocating in the heap is not a huge problem. I'm not > too fussed about this anyway because generational GC will quickly > reclaim things that die as young as this buffer does. I think you > underestimate the effectiveness of modern GC algorithms. Anyway, > optimizing here for short nm texts presumably handles the common > case. Why work hard to optimize the uncommon case? > > On Feb 25, 2008, at 10:38 AM, Jay wrote: > > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > Here is some apparently typical code: > > PROCEDURE Escape (nm: TEXT): TEXT = > VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (nm = NIL) THEN RETURN NIL; END; > len := Text.Length (nm); > IF (len + len <= NUMBER (buf)) > THEN RETURN DoEscape (nm, len, buf); > ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + > len)^); > END; > END Escape; > > PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF > CHAR): TEXT = > VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; > BEGIN > Text.SetChars (buf, nm); > FOR i := 0 TO len-1 DO > IF (buf[i] = BackSlash) THEN INC (n_escapes); END; > END; > IF (n_escapes = 0) THEN RETURN nm; END; > src := len - 1; > dest := src + n_escapes; > WHILE (src > 0) DO > c := buf[src]; DEC (src); > buf[dest] := c; DEC (dest); > IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); > END; > END; > RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); > END DoEscape; > > > Look at how inefficient this is. > For a long string it makes a heap allocation, even if in the end it > makes no changes to the string. > For any length string it copies it out to an array. > Then if there are any changes, it copies it again, probably into > heap, likely the input immediately becoming garbage. > Heap allocation may be fast, but building up garbage and causing > more work for the garbage collector I assume is bad. > And if the string had no backslashes, it's all a big waste. > > I assume texts are read only? > > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > > > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed? > Not necessarily in the language but in m3core or libm3? > Maybe it's already there? > > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a > good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => > wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not > characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:59:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:59:51 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 03:00:38 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 02:00:38 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: (sorry for the double, email problems) From: jayk123 at hotmail.com If this must be a switch, what should the default be? _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 1 15:33:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 01 Feb 2008 08:33:43 -0600 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> Message-ID: <47A32DC7.5080909@wichita.edu> Ah, and this is a systematic way of ensuring the precondition a.n=b.n always holds. Does the MIN function hint at someday generalizing to not require this condition? That would be tidy, but seems like an awful lot of work, if it is never used. Tony Hosking wrote: > Hi Rodney, > > Yes, you are missing one crucial thing. Namely, that the front-end > compiler *carefully* uses these target integer simulations only with > values that are *explicitly* the same length. LONGINT and INTEGER are > different types. INTEGER is the *representation* type for all values > 32 bits or less. LONGINT is the representation type for only LONGINT > values. You cannot mix LONGINT with INTEGER in source code > expressions. They need to be converted explicitly using ORD/VAL. > Indeed, you are right that the interfaces should document that behavior > explicitly, or alternatively, perhaps the implementations should > <*ASSERT a.n=b.n*>. The change from the way PM3 does things was > necessary for the introduction of LONGINT. > > Hope this helps and sorry for the imprecision of documentation. > > On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: > >> Whenever I run across something this unbelievable, I figure I must >> be missing something. Can anybody tell me what? >> >> While working on making Pickles work on LONGINT, I have noted the >> following code snippets for doing target arithmetic at compile time: >> >> From m3-sys/m3middle/src/Target.i3: >> >> (* The bits of a target INTEGER (in 2's complement) are stored in >> an array of small host values, with the low order bits in the first >> element of the array. *) >> >> TYPE >> Int = (* OPAQUE *) RECORD >> n: CARDINAL; (* only bytes [0..n-1] contain valid bits *) >> x := IBytes{0,..}; (* default is Zero *) >> END; >> IBytes = ARRAY [0..7] OF IByte; >> IByte = BITS 8 FOR [0..16_ff]; >> >> From m3-sys/m3middle/src/TWord.m3: >> >> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >> VAR borrow := 0; n := MIN (a.n, b.n); >> BEGIN >> <*ASSERT n # 0*> >> r.n := n; >> FOR i := 0 TO n-1 DO >> borrow := a.x[i] - b.x[i] - borrow; >> r.x[i] := Word.And (borrow, Mask); >> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >> END; >> END Subtract; >> >> Unless the two values have equal numbers of bytes, Subtract just >> throws away the high bytes of the longer operand. It looks like >> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >> does this. >> >> It seems just about inconceivable that the arithmetic could be this >> broken and not have created many impossible-to-ignore bugs. SRC >> and pm3 do it differently. They have a single global variable that >> gives the used size of all CT target values. >> >> The only possible explanation I can think of is that the cm3 compiler >> happens never to pass two Target.Int values with different values of n. >> The relevant declarations give no hint of such a counter-intuitive >> requirement. If this is an essential precondition, it should be >> documented in the interfaces. >> >> -- >> ------------------------------------------------------------- >> 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 >> >> > > -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 1 20:57:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 14:57:15 -0500 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <47A32DC7.5080909@wichita.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> <47A32DC7.5080909@wichita.edu> Message-ID: <02DFFA0A-3768-413C-8D84-0354BC9CB08A@cs.purdue.edu> On Feb 1, 2008, at 9:33 AM, Rodney M. Bates wrote: > Ah, and this is a systematic way of ensuring the precondition > a.n=b.n always holds. Does the MIN function hint at someday > generalizing to not require this condition? Yes, that's the general idea. > That would be tidy, > but seems like an awful lot of work, if it is never used. Yeah, I played around with this a great deal and decided it wasn't worth the effort. > > Tony Hosking wrote: >> Hi Rodney, >> Yes, you are missing one crucial thing. Namely, that the front- >> end compiler *carefully* uses these target integer simulations >> only with values that are *explicitly* the same length. LONGINT >> and INTEGER are different types. INTEGER is the *representation* >> type for all values 32 bits or less. LONGINT is the >> representation type for only LONGINT values. You cannot mix >> LONGINT with INTEGER in source code expressions. They need to be >> converted explicitly using ORD/VAL. Indeed, you are right that >> the interfaces should document that behavior explicitly, or >> alternatively, perhaps the implementations should <*ASSERT >> a.n=b.n*>. The change from the way PM3 does things was necessary >> for the introduction of LONGINT. >> Hope this helps and sorry for the imprecision of documentation. >> On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: >>> Whenever I run across something this unbelievable, I figure I must >>> be missing something. Can anybody tell me what? >>> >>> While working on making Pickles work on LONGINT, I have noted the >>> following code snippets for doing target arithmetic at compile time: >>> >>> From m3-sys/m3middle/src/Target.i3: >>> >>> (* The bits of a target INTEGER (in 2's complement) are stored in >>> an array of small host values, with the low order bits in the >>> first >>> element of the array. *) >>> >>> TYPE >>> Int = (* OPAQUE *) RECORD >>> n: CARDINAL; (* only bytes [0..n-1] contain valid >>> bits *) >>> x := IBytes{0,..}; (* default is Zero *) >>> END; >>> IBytes = ARRAY [0..7] OF IByte; >>> IByte = BITS 8 FOR [0..16_ff]; >>> >>> From m3-sys/m3middle/src/TWord.m3: >>> >>> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >>> VAR borrow := 0; n := MIN (a.n, b.n); >>> BEGIN >>> <*ASSERT n # 0*> >>> r.n := n; >>> FOR i := 0 TO n-1 DO >>> borrow := a.x[i] - b.x[i] - borrow; >>> r.x[i] := Word.And (borrow, Mask); >>> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >>> END; >>> END Subtract; >>> >>> Unless the two values have equal numbers of bytes, Subtract just >>> throws away the high bytes of the longer operand. It looks like >>> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >>> does this. >>> >>> It seems just about inconceivable that the arithmetic could be this >>> broken and not have created many impossible-to-ignore bugs. SRC >>> and pm3 do it differently. They have a single global variable that >>> gives the used size of all CT target values. >>> >>> The only possible explanation I can think of is that the cm3 >>> compiler >>> happens never to pass two Target.Int values with different >>> values of n. >>> The relevant declarations give no hint of such a counter-intuitive >>> requirement. If this is an essential precondition, it should be >>> documented in the interfaces. >>> >>> -- >>> ------------------------------------------------------------- >>> 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 >>> >>> > > -- > ------------------------------------------------------------- > 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 Fri Feb 1 21:26:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 01 Feb 2008 21:26:30 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> References: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> Message-ID: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 2 00:57:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 18:57:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080201234353.F351E10D4655@birch.elegosoft.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> Message-ID: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> I just checked in support for full declaration of paramters even on imported procedures in the gcc-based backend. This is to support proper generation of stdcall calling convention on Windows. In the process of testing this I discovered that cm3 on non-Windows platforms now needs to build and ship both of the Windows x86 support libraries m3back and m3objfile, even though non-Windows platforms don't use or need them. This seems broken to me. It seems that cm3 has changed so that it now has these dependencies. Can we please undo this? -- I see no need to have to build these for non-x86 platforms that will never use them. On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 08/02/02 00:43:53 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Add parameter decls even for imported procedures, as per Jay > Krell's request > to support stdcall parameter passing mode on Windows. From jayk123 at hotmail.com Sat Feb 2 01:12:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:12:27 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...). Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well? Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly. ? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 01:19:05 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:19:05 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Actually it's slightly more real than I said. One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. Sometimes it uses the "extra" code, sometimes not. These are in a sense a limited form of cross build. Granted, if it was only for those three psuedo platforms, you wouldn't mind. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hosking at elego.deDate: Sat, 2 Feb 2008 00:12:27 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...).Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well?Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly.? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:22:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:22:56 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, that gnarly x86 backend will go away soon anyway -- it's probably never going to survive in the x86_64 universe and beyond! On Feb 1, 2008, at 7:19 PM, Jay wrote: > Actually it's slightly more real than I said. > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > Sometimes it uses the "extra" code, sometimes not. These are in a > sense a limited form of cross build. Granted, if it was only for > those three psuedo platforms, you wouldn't mind. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; hosking at elego.de > Date: Sat, 2 Feb 2008 00:12:27 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > This was deliberate. It enables some cross-build scenarios. That I > admit I haven't used (yet?), but I really like the idea. > If m3linker were completed, then "full" cross builds would be real. > > The "extra" packages are small and build fast (well, at least not > using cm3cg...). > Is it really so onerous? Really? > > Isn't it nice to have less filtering of packages as well? > Like, when you are building on non-NT386, you can easily see that > you didn't break building on NT386, at least partly. > ? > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > To: hosking at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I just checked in support for full declaration of paramters even on > > imported procedures in the gcc-based backend. This is to support > > proper generation of stdcall calling convention on Windows. In the > > process of testing this I discovered that cm3 on non-Windows > > platforms now needs to build and ship both of the Windows x86 > support > > libraries m3back and m3objfile, even though non-Windows platforms > > don't use or need them. This seems broken to me. It seems that cm3 > > has changed so that it now has these dependencies. Can we please > > undo this? -- I see no need to have to build these for non-x86 > > platforms that will never use them. > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > Add parameter decls even for imported procedures, as per Jay > > > Krell's request > > > to support stdcall parameter passing mode on Windows. > > > > > Connect and share in new ways with Windows Live. Get it now! > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From jayk123 at hotmail.com Sat Feb 2 01:45:25 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:45:25 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:22:56 -0500> To: jayk123 at hotmail.com> > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond!> > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > > Actually it's slightly more real than I said.> > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu; hosking at elego.de> > Date: Sat, 2 Feb 2008 00:12:27 +0000> > CC: m3devel at elegosoft.com> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> >> > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea.> > If m3linker were completed, then "full" cross builds would be real.> >> > The "extra" packages are small and build fast (well, at least not > > using cm3cg...).> > Is it really so onerous? Really?> >> > Isn't it nice to have less filtering of packages as well?> > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly.> > ?> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > To: hosking at elego.de> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > >> > > I just checked in support for full declaration of paramters even on> > > imported procedures in the gcc-based backend. This is to support> > > proper generation of stdcall calling convention on Windows. In the> > > process of testing this I discovered that cm3 on non-Windows> > > platforms now needs to build and ship both of the Windows x86 > > support> > > libraries m3back and m3objfile, even though non-Windows platforms> > > don't use or need them. This seems broken to me. It seems that cm3> > > has changed so that it now has these dependencies. Can we please> > > undo this? -- I see no need to have to build these for non-x86> > > platforms that will never use them.> > >> > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > >> > > > CVSROOT: /usr/cvs> > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > >> > > > Modified files:> > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > >> > > > Log message:> > > > Add parameter decls even for imported procedures, as per Jay> > > > Krell's request> > > > to support stdcall parameter passing mode on Windows.> > >> >> >> > Connect and share in new ways with Windows Live. Get it now!> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:56:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:56:18 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> It would be nice to have the x86 integrated backend for I386_LINUX and LINUXLIBC6 too -- just like the old PM3 did. On Feb 1, 2008, at 7:45 PM, Jay wrote: > Hey, I'd kind of like that backend to stay actually. It's quite > fast and generates better code than unoptimized gcc and competitive > code with optimized gcc. There's no AMD64 support anywhere yet in > Modula-3 that I know of. Maybe it will appear here first? :) > > I don't think it is all that gnarly either. But somewhat. It's a > bit like code I've see that is so often handling one case after > another case after yet another case, yet who knows what all the > cases are and which order (if any particular) they should be > handled in? That is, it's actually kind of easier to read it and > understand what it does do, and realize that is "correct" in the > "necessary" sense, but hard to know if it is "sufficient". > I've got outstanding diffs for int64 support I'd like to get back to. > > AMD64 shouldn't be difficult...that's kind of the point, eh? > It's just a slight alteration of x86.. > > Granted, it isn't set up, doesn't have a "framework", to generate > substantially better code. > It doesn't remember much, doesn't make multiple passes, doesn't > have a high level representation, etc. > > In the unlikely event that I succeed, presumably PPC would be > next...:) > > (But yeah yeah, LLVM is probably easier and much more fruitful, > both in terms of platform each and optimization..and hopefully > build speed.) > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > To: jayk123 at hotmail.com > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > that gnarly x86 backend will go away soon anyway -- it's probably > > never going to survive in the x86_64 universe and beyond! > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > Actually it's slightly more real than I said. > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > sense a limited form of cross build. Granted, if it was only for > > > those three psuedo platforms, you wouldn't mind. > > > > > > - Jay > > > > > > From: jayk123 at hotmail.com > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > admit I haven't used (yet?), but I really like the idea. > > > If m3linker were completed, then "full" cross builds would be > real. > > > > > > The "extra" packages are small and build fast (well, at least not > > > using cm3cg...). > > > Is it really so onerous? Really? > > > > > > Isn't it nice to have less filtering of packages as well? > > > Like, when you are building on non-NT386, you can easily see that > > > you didn't break building on NT386, at least partly. > > > ? > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > To: hosking at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > I just checked in support for full declaration of paramters > even on > > > > imported procedures in the gcc-based backend. This is to support > > > > proper generation of stdcall calling convention on Windows. > In the > > > > process of testing this I discovered that cm3 on non-Windows > > > > platforms now needs to build and ship both of the Windows x86 > > > support > > > > libraries m3back and m3objfile, even though non-Windows > platforms > > > > don't use or need them. This seems broken to me. It seems > that cm3 > > > > has changed so that it now has these dependencies. Can we please > > > > undo this? -- I see no need to have to build these for non-x86 > > > > platforms that will never use them. > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > CVSROOT: /usr/cvs > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > Modified files: > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > Log message: > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > Krell's request > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From rcoleburn at scires.com Sat Feb 2 01:57:24 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 19:57:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <47A379A4.1E75.00D7.1@scires.com> I too want to keep that backend. All of my Modula-3 production code in the past was built using it. Regards, Randy >>> Jay 2/1/2008 7:45 PM >>> Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:22:56 -0500 > To: jayk123 at hotmail.com > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond! > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > Actually it's slightly more real than I said. > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu; hosking at elego.de > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea. > > If m3linker were completed, then "full" cross builds would be real. > > > > The "extra" packages are small and build fast (well, at least not > > using cm3cg...). > > Is it really so onerous? Really? > > > > Isn't it nice to have less filtering of packages as well? > > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly. > > ? > > > > - Jay > > > > > > > From: hosking at cs.purdue.edu > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > To: hosking at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > I just checked in support for full declaration of paramters even on > > > imported procedures in the gcc-based backend. This is to support > > > proper generation of stdcall calling convention on Windows. In the > > > process of testing this I discovered that cm3 on non-Windows > > > platforms now needs to build and ship both of the Windows x86 > > support > > > libraries m3back and m3objfile, even though non-Windows platforms > > > don't use or need them. This seems broken to me. It seems that cm3 > > > has changed so that it now has these dependencies. Can we please > > > undo this? -- I see no need to have to build these for non-x86 > > > platforms that will never use them. > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > Modified files: > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > Log message: > > > > Add parameter decls even for imported procedures, as per Jay > > > > Krell's request > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Shed those extra pounds with MSN and The Biggest Loser! Learn more. ( http://biggestloser.msn.com/ ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:02:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:02:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sat Feb 2 02:08:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 20:08:59 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <47A37C5A.1E75.00D7.1@scires.com> Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy >>> Jay 2/1/2008 8:02 PM >>> "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:56:18 -0500 > To: jayk123 at hotmail.com > > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did. > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient". > > I've got outstanding diffs for int64 support I'd like to get back to. > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > It's just a slight alteration of x86.. > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code. > > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc. > > > > In the unlikely event that I succeed, presumably PPC would be > > next...:) > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.) > > > > - Jay > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > To: jayk123 at hotmail.com > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > that gnarly x86 backend will go away soon anyway -- it's probably > > > never going to survive in the x86_64 universe and beyond! > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > Actually it's slightly more real than I said. > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > > sense a limited form of cross build. Granted, if it was only for > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > > admit I haven't used (yet?), but I really like the idea. > > > > If m3linker were completed, then "full" cross builds would be > > real. > > > > > > > > The "extra" packages are small and build fast (well, at least not > > > > using cm3cg...). > > > > Is it really so onerous? Really? > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > Like, when you are building on non-NT386, you can easily see that > > > > you didn't break building on NT386, at least partly. > > > > ? > > > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > To: hosking at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > I just checked in support for full declaration of paramters > > even on > > > > > imported procedures in the gcc-based backend. This is to support > > > > > proper generation of stdcall calling convention on Windows. > > In the > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > platforms now needs to build and ship both of the Windows x86 > > > > support > > > > > libraries m3back and m3objfile, even though non-Windows > > platforms > > > > > don't use or need them. This seems broken to me. It seems > > that cm3 > > > > > has changed so that it now has these dependencies. Can we please > > > > > undo this? -- I see no need to have to build these for non-x86 > > > > > platforms that will never use them. > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > Modified files: > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > Log message: > > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > > Krell's request > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more. > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:19:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:19:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47A37C5A.1E75.00D7.1@scires.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> <47A37C5A.1E75.00D7.1@scires.com> Message-ID: No. (I fully admit I don't know yet what the problem is, and the way the system is designed in my understanding, variations like this are "impossible", therefore throw out nearly all expectations and entertain nearly all ideas, but I don't think this is related. It'll just have to be debugged and code studied and skimmed for hints, and I apologize for the long delay. Maybe some code checks for function equality?? (not sure Modula-3 even supports that, but it's one the small subtleties of dynamic linking that can trip up some unusual slightly sleazy C code)) - Jay Date: Fri, 1 Feb 2008 20:08:59 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; jayk123 at hotmail.comCC: hosking at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy>>> Jay 2/1/2008 8:02 PM >>>"I386_LINUX"? You aren't off renaming platforms now are you Tony? :)Agreed. I stopped looking when I noticed the license..Aha..I guess that is the point of the two "integrated" x86 backends?There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe.The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that...You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 03:23:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 21:23:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <3F43F984-4CF8-4F74-A422-0F129FD00707@cs.purdue.edu> Sorry: I386_DARWIN. On Feb 1, 2008, at 8:02 PM, Jay wrote: > "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) > Agreed. I stopped looking when I noticed the license.. > Aha..I guess that is the point of the two "integrated" x86 backends? > There's just one code base, there there is m3back and > m3staloneback. One builds a .lib, one builds an .exe. > The .exe probably reads the binary file and then replays the > function calls..it's marshaling layer and all that... > You can move the code around to avoid spreading the license and all > that.. > > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:56:18 -0500 > > To: jayk123 at hotmail.com > > > > It would be nice to have the x86 integrated backend for I386_LINUX > > and LINUXLIBC6 too -- just like the old PM3 did. > > > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > > > Hey, I'd kind of like that backend to stay actually. It's quite > > > fast and generates better code than unoptimized gcc and > competitive > > > code with optimized gcc. There's no AMD64 support anywhere yet in > > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > > > I don't think it is all that gnarly either. But somewhat. It's a > > > bit like code I've see that is so often handling one case after > > > another case after yet another case, yet who knows what all the > > > cases are and which order (if any particular) they should be > > > handled in? That is, it's actually kind of easier to read it and > > > understand what it does do, and realize that is "correct" in the > > > "necessary" sense, but hard to know if it is "sufficient". > > > I've got outstanding diffs for int64 support I'd like to get > back to. > > > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > > It's just a slight alteration of x86.. > > > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > > substantially better code. > > > It doesn't remember much, doesn't make multiple passes, doesn't > > > have a high level representation, etc. > > > > > > In the unlikely event that I succeed, presumably PPC would be > > > next...:) > > > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > > both in terms of platform each and optimization..and hopefully > > > build speed.) > > > > > > - Jay > > > > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > > that gnarly x86 backend will go away soon anyway -- it's > probably > > > > never going to survive in the x86_64 universe and beyond! > > > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > > > Actually it's slightly more real than I said. > > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/ > NT386MINGNU. > > > > > Sometimes it uses the "extra" code, sometimes not. These > are in a > > > > > sense a limited form of cross build. Granted, if it was > only for > > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > > > - Jay > > > > > > > > > > From: jayk123 at hotmail.com > > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > This was deliberate. It enables some cross-build scenarios. > That I > > > > > admit I haven't used (yet?), but I really like the idea. > > > > > If m3linker were completed, then "full" cross builds would be > > > real. > > > > > > > > > > The "extra" packages are small and build fast (well, at > least not > > > > > using cm3cg...). > > > > > Is it really so onerous? Really? > > > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > > Like, when you are building on non-NT386, you can easily > see that > > > > > you didn't break building on NT386, at least partly. > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > > To: hosking at elego.de > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > > > I just checked in support for full declaration of paramters > > > even on > > > > > > imported procedures in the gcc-based backend. This is to > support > > > > > > proper generation of stdcall calling convention on Windows. > > > In the > > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > > platforms now needs to build and ship both of the Windows > x86 > > > > > support > > > > > > libraries m3back and m3objfile, even though non-Windows > > > platforms > > > > > > don't use or need them. This seems broken to me. It seems > > > that cm3 > > > > > > has changed so that it now has these dependencies. Can we > please > > > > > > undo this? -- I see no need to have to build these for > non-x86 > > > > > > platforms that will never use them. > > > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > > > Modified files: > > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > > > Log message: > > > > > > > Add parameter decls even for imported procedures, as > per Jay > > > > > > > Krell's request > > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > > more. > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 07:23:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 06:23:09 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <20080204054529.A4C4F10D4611@birch.elegosoft.com> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: (and codegen..) C:\dev2\j\m3\t>type t.c typedef struct { int a,b,c,d,e,f;} Foo_t; void __stdcall Sleep(Foo_t foo); extern Foo_t a; void F1(){ Sleep(a);} C:\dev2\j\m3\t>gcc -c -S t.c C:\dev2\j\m3\t>type t.s .file "t.c" .text.globl _F1 .def _F1; .scl 2; .type 32; .endef_F1: pushl %ebp movl %esp, %ebp subl $24, %esp movl _a, %eax movl %eax, (%esp) movl _a+4, %eax movl %eax, 4(%esp) movl _a+8, %eax movl %eax, 8(%esp) movl _a+12, %eax movl %eax, 12(%esp) movl _a+16, %eax movl %eax, 16(%esp) movl _a+20, %eax movl %eax, 20(%esp) call _Sleep at 24 subl $24, %esp leave ret C:\dev2\j\m3\t>(NOTE: This is NOT the correct declaration of Sleep, but ok for testing purposes.) C:\dev2\j\m3\t>type t.i3INTERFACE T; TYPE Foo_t = RECORD a,b,c,d,e,f : INTEGER;END; <*EXTERNAL Sleep:WINAPI*>PROCEDURE Sleep (dwMilliseconds1: Foo_t); END T. C:\dev2\j\m3\t>type t.m3 MODULE T; VAR Foo: Foo_t; BEGIN Sleep(Foo);END T. LM1: movl 8(%ebp), %eax xorl $1, %eax testb %al, %al jne L2 .stabn 68,0,6,LM2-_T_M3LM2: movl $_MM_T+52, %eax movl %eax, %edx subl $8, %esp subl $24, %esp movl %esp, %eax movl %eax, %edi movl %edx, %esi cld movl $6, %eax movl %eax, %ecx rep movsl call _Sleep at 4 addl $8, %espL2: movl $_MM_T, %eaxLBE2: leal -8(%ebp), %esp popl %esi popl %edi leave ret ? - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 15:52:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 09:52:31 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: Any chance that standard_structs in Target.i3 is causing the front- end to pass structs by reference (standard structs=TRUE)? Also, looking at pop_struct in parse.c it seems to want to pass them by reference (standard_structs=FALSE)? In any case, what does the integrated back-end do with pop_struct? I bet it is passing by value... whereas parse.c passes by ref. Blurgh! Looks like we need to smarten things up for calls to non-M3 stdcall procedures. On Feb 4, 2008, at 1:23 AM, Jay wrote: > (and codegen..) > > C:\dev2\j\m3\t>type t.c > > typedef struct { > int a,b,c,d,e,f; > } Foo_t; > > void __stdcall Sleep(Foo_t foo); > > extern Foo_t a; > > void F1() > { > Sleep(a); > } > > C:\dev2\j\m3\t>gcc -c -S t.c > > C:\dev2\j\m3\t>type t.s > .file "t.c" > .text > .globl _F1 > .def _F1; .scl 2; .type 32; .endef > _F1: > pushl %ebp > movl %esp, %ebp > subl $24, %esp > movl _a, %eax > movl %eax, (%esp) > movl _a+4, %eax > movl %eax, 4(%esp) > movl _a+8, %eax > movl %eax, 8(%esp) > movl _a+12, %eax > movl %eax, 12(%esp) > movl _a+16, %eax > movl %eax, 16(%esp) > movl _a+20, %eax > movl %eax, 20(%esp) > call _Sleep at 24 > subl $24, %esp > leave > ret > C:\dev2\j\m3\t> > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > testing purposes.) > > C:\dev2\j\m3\t>type t.i3 > INTERFACE T; > > TYPE Foo_t = RECORD > a,b,c,d,e,f : INTEGER; > END; > > <*EXTERNAL Sleep:WINAPI*> > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > END T. > > C:\dev2\j\m3\t>type t.m3 > > MODULE T; > VAR > Foo: Foo_t; > > BEGIN > Sleep(Foo); > END T. > > > LM1: > movl 8(%ebp), %eax > xorl $1, %eax > testb %al, %al > jne L2 > .stabn 68,0,6,LM2-_T_M3 > LM2: > movl $_MM_T+52, %eax > movl %eax, %edx > subl $8, %esp > subl $24, %esp > movl %esp, %eax > movl %eax, %edi > movl %edx, %esi > cld > movl $6, %eax > movl %eax, %ecx > rep > movsl > call _Sleep at 4 > addl $8, %esp > L2: > movl $_MM_T, %eax > LBE2: > leal -8(%ebp), %esp > popl %esi > popl %edi > leave > ret > > ? > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 20:43:43 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:43:43 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I think they are being passed correctly, by value. pop_struct and not pop_param is used. When I get time, I will put my parse.c back (uncommited) and then just try some tests with "__cdecl" passing and returning structs. That removes the naming issue and PART of the calling convention issue and tests what is left. Then I'll see if I can hack something up to test the rest. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 20:46:00 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:46:00 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures. ps: m3 or not m3 I would think. stdcall is stdcall, independent of the implementing language. Though sure, the C declaration could declare the thing by const pointer. Given some existing unchanged C declarations for "callbacks" however, I should be able to implement them in M3. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 21:30:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:23 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> OK. Not sure I understand what is going on then -- I would like to see the .mc file to get a sense of things. On Feb 4, 2008, at 2:43 PM, Jay wrote: > I think they are being passed correctly, by value. pop_struct and > not pop_param is used. > When I get time, I will put my parse.c back (uncommited) and then > just try some tests with "__cdecl" passing and returning structs. > That removes the naming issue and PART of the calling convention > issue and tests what is left. > Then I'll see if I can hack something up to test the rest. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From hosking at cs.purdue.edu Mon Feb 4 21:30:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:59 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I don't think I follow you. On Feb 4, 2008, at 2:46 PM, Jay wrote: > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > the implementing language. > Though sure, the C declaration could declare the thing by const > pointer. > > Given some existing unchanged C declarations for "callbacks" > however, I should be able to implement them in M3. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From jayk123 at hotmail.com Mon Feb 4 21:38:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:38:28 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > > > to smarten things up for calls to non-M3 stdcall procedures. Why is the smartening specific to non-M3 procedures?I should be able to write stdcall functions in M3 as well, that take and return structs, I am so inclined or "forced". (Arguably, it should be the default. It is slightly more efficient.) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:59 -0500> To: jayk123 at hotmail.com> > I don't think I follow you.> > On Feb 4, 2008, at 2:46 PM, Jay wrote:> > > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> >> > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > the implementing language.> > Though sure, the C declaration could declare the thing by const > > pointer.> >> > Given some existing unchanged C declarations for "callbacks" > > however, I should be able to implement them in M3.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 21:51:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:51:01 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working. m3quake => sysutils => libm3/TextExtras but TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do. I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 22:01:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:01:44 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: This is without your most recent changes. > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:23 -0500> To: jayk123 at hotmail.com> > OK. Not sure I understand what is going on then -- I would like to > see the .mc file to get a sense of things.> > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > > I think they are being passed correctly, by value. pop_struct and > > not pop_param is used.> > When I get time, I will put my parse.c back (uncommited) and then > > just try some tests with "__cdecl" passing and returning structs. > > That removes the naming issue and PART of the calling convention > > issue and tests what is left.> > Then I'll see if I can hack something up to test the rest.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:05:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:05:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <927CD38A-8DA0-4963-83D4-265C9098BDCC@cs.purdue.edu> I agree. I was suspicious of the standard_structs flag -- you probably know better than I do what it is supposed to do. On Feb 4, 2008, at 3:38 PM, Jay wrote: > > > > to smarten things up for calls to non-M3 stdcall procedures. > > Why is the smartening specific to non-M3 procedures? > I should be able to write stdcall functions in M3 as well, that > take and return structs, I am so inclined or "forced". > (Arguably, it should be the default. It is slightly more efficient.) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:59 -0500 > > To: jayk123 at hotmail.com > > > > I don't think I follow you. > > > > On Feb 4, 2008, at 2:46 PM, Jay wrote: > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > > the implementing language. > > > Though sure, the C declaration could declare the thing by const > > > pointer. > > > > > > Given some existing unchanged C declarations for "callbacks" > > > however, I should be able to implement them in M3. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 4 22:09:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:09:50 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: 5.1.8 worked From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: bootstrapping from old versions?Date: Mon, 4 Feb 2008 20:51:01 +0000 It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working.m3quake => sysutils => libm3/TextExtrasbut TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do.I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 22:19:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:19:38 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: Jay, I'm not on Windows so I can't diagnose the stdcall problem. I want to see the .mc file so I can get a sense of what is going on. On Feb 4, 2008, at 4:01 PM, Jay wrote: > This is without your most recent changes. > > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > To: jayk123 at hotmail.com > > > > OK. Not sure I understand what is going on then -- I would like to > > see the .mc file to get a sense of things. > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > I think they are being passed correctly, by value. pop_struct and > > > not pop_param is used. > > > When I get time, I will put my parse.c back (uncommited) and then > > > just try some tests with "__cdecl" passing and returning structs. > > > That removes the naming issue and PART of the calling convention > > > issue and tests what is left. > > > Then I'll see if I can hack something up to test the rest. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Connect and share in new ways with Windows Live. Get it now! > From jayk123 at hotmail.com Mon Feb 4 22:28:49 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:28:49 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: understood, did the attachment not come through? attached again (parse.c changes aren't really relevant here anyway, not for the *c files, but for the *s files) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 16:19:38 -0500> To: jayk123 at hotmail.com> > Jay,> > I'm not on Windows so I can't diagnose the stdcall problem. I want > to see the .mc file so I can get a sense of what is going on.> > On Feb 4, 2008, at 4:01 PM, Jay wrote:> > > This is without your most recent changes.> >> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 15:30:23 -0500> > > To: jayk123 at hotmail.com> > >> > > OK. Not sure I understand what is going on then -- I would like to> > > see the .mc file to get a sense of things.> > >> > > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > >> > > > I think they are being passed correctly, by value. pop_struct and> > > > not pop_param is used.> > > > When I get time, I will put my parse.c back (uncommited) and then> > > > just try some tests with "__cdecl" passing and returning structs.> > > > That removes the naming issue and PART of the calling convention> > > > issue and tests what is left.> > > > Then I'll see if I can hack something up to test the rest.> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: stdcall naming discrepancy?> > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > > Any chance that standard_structs in Target.i3 is causing the > > front-> > > > > end to pass structs by reference (standard structs=TRUE)? Also,> > > > > looking at pop_struct in parse.c it seems to want to pass > > them by> > > > > reference (standard_structs=FALSE)? In any case, what does the> > > > > integrated back-end do with pop_struct? I bet it is passing by> > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > > need> > > > > to smarten things up for calls to non-M3 stdcall procedures.> > > > >> > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > > >> > > > > > (and codegen..)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.c> > > > > >> > > > > > typedef struct {> > > > > > int a,b,c,d,e,f;> > > > > > } Foo_t;> > > > > >> > > > > > void __stdcall Sleep(Foo_t foo);> > > > > >> > > > > > extern Foo_t a;> > > > > >> > > > > > void F1()> > > > > > {> > > > > > Sleep(a);> > > > > > }> > > > > >> > > > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > > > >> > > > > > C:\dev2\j\m3\t>type t.s> > > > > > .file "t.c"> > > > > > .text> > > > > > .globl _F1> > > > > > .def _F1; .scl 2; .type 32; .endef> > > > > > _F1:> > > > > > pushl %ebp> > > > > > movl %esp, %ebp> > > > > > subl $24, %esp> > > > > > movl _a, %eax> > > > > > movl %eax, (%esp)> > > > > > movl _a+4, %eax> > > > > > movl %eax, 4(%esp)> > > > > > movl _a+8, %eax> > > > > > movl %eax, 8(%esp)> > > > > > movl _a+12, %eax> > > > > > movl %eax, 12(%esp)> > > > > > movl _a+16, %eax> > > > > > movl %eax, 16(%esp)> > > > > > movl _a+20, %eax> > > > > > movl %eax, 20(%esp)> > > > > > call _Sleep at 24> > > > > > subl $24, %esp> > > > > > leave> > > > > > ret> > > > > > C:\dev2\j\m3\t>> > > > > >> > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > > for> > > > > > testing purposes.)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.i3> > > > > > INTERFACE T;> > > > > >> > > > > > TYPE Foo_t = RECORD> > > > > > a,b,c,d,e,f : INTEGER;> > > > > > END;> > > > > >> > > > > > <*EXTERNAL Sleep:WINAPI*>> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > > > END T.> > > > > >> > > > > > C:\dev2\j\m3\t>type t.m3> > > > > >> > > > > > MODULE T;> > > > > > VAR> > > > > > Foo: Foo_t;> > > > > >> > > > > > BEGIN> > > > > > Sleep(Foo);> > > > > > END T.> > > > > >> > > > > >> > > > > > LM1:> > > > > > movl 8(%ebp), %eax> > > > > > xorl $1, %eax> > > > > > testb %al, %al> > > > > > jne L2> > > > > > .stabn 68,0,6,LM2-_T_M3> > > > > > LM2:> > > > > > movl $_MM_T+52, %eax> > > > > > movl %eax, %edx> > > > > > subl $8, %esp> > > > > > subl $24, %esp> > > > > > movl %esp, %eax> > > > > > movl %eax, %edi> > > > > > movl %edx, %esi> > > > > > cld> > > > > > movl $6, %eax> > > > > > movl %eax, %ecx> > > > > > rep> > > > > > movsl> > > > > > call _Sleep at 4> > > > > > addl $8, %esp> > > > > > L2:> > > > > > movl $_MM_T, %eax> > > > > > LBE2:> > > > > > leal -8(%ebp), %esp> > > > > > popl %esi> > > > > > popl %edi> > > > > > leave> > > > > > ret> > > > > >> > > > > > ?> > > > > >> > > > > > - Jay> > > > > >> > > > > > Connect and share in new ways with Windows Live. Get it now!> > > > >> > > >> > > >> > > > Climb to the top of the charts! Play the word scramble challenge> > > > with star power. Play now!> > >> >> >> > Connect and share in new ways with Windows Live. Get it now! > > > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:59:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:59:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: I just checked in a fix that initializes void_list_node. I think this may be the fix you need for stdargs. As far as I know, void_list_node is used to mark the end of non-varargs parameter lists. On Feb 4, 2008, at 4:28 PM, Jay wrote: > understood, did the attachment not come through? > attached again > (parse.c changes aren't really relevant here anyway, not for the *c > files, but for the *s files) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 16:19:38 -0500 > > To: jayk123 at hotmail.com > > > > Jay, > > > > I'm not on Windows so I can't diagnose the stdcall problem. I want > > to see the .mc file so I can get a sense of what is going on. > > > > On Feb 4, 2008, at 4:01 PM, Jay wrote: > > > > > This is without your most recent changes. > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > OK. Not sure I understand what is going on then -- I would > like to > > > > see the .mc file to get a sense of things. > > > > > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > > > > > I think they are being passed correctly, by value. > pop_struct and > > > > > not pop_param is used. > > > > > When I get time, I will put my parse.c back (uncommited) > and then > > > > > just try some tests with "__cdecl" passing and returning > structs. > > > > > That removes the naming issue and PART of the calling > convention > > > > > issue and tests what is left. > > > > > Then I'll see if I can hack something up to test the rest. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: stdcall naming discrepancy? > > > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > > > front- > > > > > > end to pass structs by reference (standard structs=TRUE)? > Also, > > > > > > looking at pop_struct in parse.c it seems to want to pass > > > them by > > > > > > reference (standard_structs=FALSE)? In any case, what > does the > > > > > > integrated back-end do with pop_struct? I bet it is > passing by > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks > like we > > > need > > > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > > > > > (and codegen..) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > > > > > typedef struct { > > > > > > > int a,b,c,d,e,f; > > > > > > > } Foo_t; > > > > > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > > > > > extern Foo_t a; > > > > > > > > > > > > > > void F1() > > > > > > > { > > > > > > > Sleep(a); > > > > > > > } > > > > > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > > > .file "t.c" > > > > > > > .text > > > > > > > .globl _F1 > > > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > > > _F1: > > > > > > > pushl %ebp > > > > > > > movl %esp, %ebp > > > > > > > subl $24, %esp > > > > > > > movl _a, %eax > > > > > > > movl %eax, (%esp) > > > > > > > movl _a+4, %eax > > > > > > > movl %eax, 4(%esp) > > > > > > > movl _a+8, %eax > > > > > > > movl %eax, 8(%esp) > > > > > > > movl _a+12, %eax > > > > > > > movl %eax, 12(%esp) > > > > > > > movl _a+16, %eax > > > > > > > movl %eax, 16(%esp) > > > > > > > movl _a+20, %eax > > > > > > > movl %eax, 20(%esp) > > > > > > > call _Sleep at 24 > > > > > > > subl $24, %esp > > > > > > > leave > > > > > > > ret > > > > > > > C:\dev2\j\m3\t> > > > > > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, > but ok > > > for > > > > > > > testing purposes.) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > > > INTERFACE T; > > > > > > > > > > > > > > TYPE Foo_t = RECORD > > > > > > > a,b,c,d,e,f : INTEGER; > > > > > > > END; > > > > > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > > > END T. > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > > > > > MODULE T; > > > > > > > VAR > > > > > > > Foo: Foo_t; > > > > > > > > > > > > > > BEGIN > > > > > > > Sleep(Foo); > > > > > > > END T. > > > > > > > > > > > > > > > > > > > > > LM1: > > > > > > > movl 8(%ebp), %eax > > > > > > > xorl $1, %eax > > > > > > > testb %al, %al > > > > > > > jne L2 > > > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > > > LM2: > > > > > > > movl $_MM_T+52, %eax > > > > > > > movl %eax, %edx > > > > > > > subl $8, %esp > > > > > > > subl $24, %esp > > > > > > > movl %esp, %eax > > > > > > > movl %eax, %edi > > > > > > > movl %edx, %esi > > > > > > > cld > > > > > > > movl $6, %eax > > > > > > > movl %eax, %ecx > > > > > > > rep > > > > > > > movsl > > > > > > > call _Sleep at 4 > > > > > > > addl $8, %esp > > > > > > > L2: > > > > > > > movl $_MM_T, %eax > > > > > > > LBE2: > > > > > > > leal -8(%ebp), %esp > > > > > > > popl %esi > > > > > > > popl %edi > > > > > > > leave > > > > > > > ret > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it > now! > > > > > > > > > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble > challenge > > > > > with star power. Play now! > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 4 23:14:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 17:14:16 -0500 Subject: [M3devel] Latest parse.c Message-ID: See this snip from gcc/gcc/config/winnt.c: > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl)); > if (formal_type != NULL_TREE) > { > /* These attributes are ignored for variadic functions in > i386.c:ix86_return_pops_args. For compatibility with MS > compiler do not add @0 suffix here. */ > if (TREE_VALUE (tree_last (formal_type)) != void_type_node) > return DECL_ASSEMBLER_NAME (decl); We need a void_type_node there -- void_list_node now captures that properly. > /* Quit if we hit an incomplete type. Error is reported > by convert_arguments in c-typeck.c or cp/typeck.c. */ I wonder if the remaining problem with the wrong @N value is because we don't have a complete type on the formals? > while (TREE_VALUE (formal_type) != void_type_node > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > { > int parm_size > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type))); > /* Must round up to include padding. This is done the same > way as in store_one_arg. */ > parm_size = ((parm_size + PARM_BOUNDARY - 1) > / PARM_BOUNDARY * PARM_BOUNDARY); > total += parm_size; > formal_type = TREE_CHAIN (formal_type);\ > } > } From jayk123 at hotmail.com Mon Feb 4 23:25:52 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 22:25:52 +0000 Subject: [M3devel] Latest parse.c In-Reply-To: References: Message-ID: I'll try later. I tried stepping through some of this in gdb but couldn't make much sense of the data. Perhaps due to optimization. And I read some of it, but didn't really notice what you point out, thanks. I need to be more willing to resort to printf debugging..it worked well with those aligned doubles.. It should help (any of us) to use that small repro I provided. I don't think it "quits" for us, but worth the printf'ing and such. It does append "@4" to Sleep. Another thing would be try: like Sleep(int,record,int,record); I wouldn't be surprised if you get @16, but I'm placing no bets here. :) I should also try building some cross m3cg's so I can nag you to do the same. :) (if it only it were that easy, also need cross gcc, ld, headers, libs, and then could build all distributions from one machine, albeit NT386 is the real laggard here...) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Latest parse.c> Date: Mon, 4 Feb 2008 17:14:16 -0500> To: jayk123 at hotmail.com> > See this snip from gcc/gcc/config/winnt.c:> > > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl));> > if (formal_type != NULL_TREE)> > {> > /* These attributes are ignored for variadic functions in> > i386.c:ix86_return_pops_args. For compatibility with MS> > compiler do not add @0 suffix here. */> > if (TREE_VALUE (tree_last (formal_type)) != void_type_node)> > return DECL_ASSEMBLER_NAME (decl);> > We need a void_type_node there -- void_list_node now captures that > properly.> > > /* Quit if we hit an incomplete type. Error is reported> > by convert_arguments in c-typeck.c or cp/typeck.c. */> > I wonder if the remaining problem with the wrong @N value is because > we don't have a complete type on the formals?> > > while (TREE_VALUE (formal_type) != void_type_node> > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > > {> > int parm_size> > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type)));> > /* Must round up to include padding. This is done the same> > way as in store_one_arg. */> > parm_size = ((parm_size + PARM_BOUNDARY - 1)> > / PARM_BOUNDARY * PARM_BOUNDARY);> > total += parm_size;> > formal_type = TREE_CHAIN (formal_type);\> > }> > }> > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 5 10:36:55 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 5 Feb 2008 09:36:55 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801291036.m0TAaVws062299@camembert.async.caltech.edu> References: Your message of "Mon, 28 Jan 2008 12:38:38 GMT." <200801291036.m0TAaVws062299@camembert.async.caltech.edu> Message-ID: Mika you are right, e.g.: C:\pm3\bin>mentor.exe ****** runtime error:*** ThreadWin32.m3, line 726: Windows OS failure, GetLastError = 8*** use option @M3stackdump to get a stack trace 20754 [unknown (0xF84)] mentor 2780 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 42083 [unknown (0xF84)] mentor 2780 open_stackdumpfile: Dumping stack trace to mentor.exe.stackdump And it uses Win32 gui. I am still inclined to use pthreads though.. - Jay > To: jayk123 at hotmail.com> Subject: Re: [M3devel] nt386gnu threads? > Date: Tue, 29 Jan 2008 02:36:31 -0800> From: mika at async.caltech.edu> > > Sorry, I don't have the m3makefiles. I just have a binary installation> of PM3/Klagenfurt.> > Practice your German:> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > here...> > http://www.1o0.de/wi-links/modula3/> > (Sorry I don't even have access to my Windows system right now.)> > Mika> > Jay writes:> >--_14fad708-4bac-4aaf-ab93-c9649038a920_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Um, so the file exists..does it get compiled? Did you look at the m3makefil=> >es?> >I skimmed the m3makefiles. I have not tried building PM3 myself.> >=20> > - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Feb 5 12:15:44 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 5 Feb 2008 12:15:44 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Message-ID: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Hi Olaf: Is still possible to add Literate programming support, I mean using several functions that are just a commentary at the end of the file on M3Build.m3: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain Also there is a missing one on Built-in functions, one that "copy" the derived source of a noweb file (specifically a generic) from the Target (e.g LINUXLIBC6) directory of the compiler to the src directory. In that way the compiler can use the source. The name of functions could be: "derived_generic_interface", "derived_generic_implementation" This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ The literate programming support was present on DEC SRC M3 I think: http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Thanks Daniel Benavides Olaf Wagner escribi?: Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 5 12:39:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 05 Feb 2008 12:39:23 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080205123923.qvlr4noeocgkc8gs@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain You're talking of the builder's built-in functions; I haven't had a close look at them yet (just extended the pure quake built-ins). Of course it should be possible to add support for literate programming; but I haven't any experience with this. > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. I don't think it should be done this way, and it wouldn't really work, as the compiler would need two passes for each package then; all derived files should be kept in the TARGET directory. I think derived sources for literate programming should be handled in the same way as instantiated generics (e.g. based on quake templates). > In that way the compiler can use the source. The name of functions > could be: "derived_generic_interface", > "derived_generic_implementation" The actual implementation could be done in quake first and maybe later be implemented in M3 in the builder for performance reasons. > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html As I said, I've never used it and don't know about it, but will have a look at it when I've got some time. If you could provide some of the needed quake functions, that would of course 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 Wed Feb 6 20:15:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 06 Feb 2008 20:15:26 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 6 22:46:31 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 6 Feb 2008 21:46:31 +0000 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: Modula-3 and quake both support writing comments already. :) I guess a "cross referencing" scheme would be nice, but to some extent that should be automatic. To some extent, or entirely, it is what Reactor is. All the calls to a function or references to a type are immediately findable, I think. All you really need is a) a completely global namespace so every identifier is unique b) plain text search based on an index. I like C++ and I like some about Modula-3, but hierarchical namespaces really stink in the face of (indexed) plain text search, and no other kind of search can keep up with large codebases. How do I find uses of this particular "T" when people can and do make aliases? I realize C has typedefs to establish aliases, and nesting, so that argument is somewhat moot (the point is more relevant for C++, trying to make it Modula-3-relevant). In C++, how do I search for calls to a particular operator=? Or to a constructor? I'm just being obnoxious. ...Jay > Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dabenavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." :> > > Hi Olaf:> > Is still possible to add Literate programming support, I mean using > > several functions that are just a commentary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain> >> > Also there is a missing one on Built-in functions, one that "copy" > > the derived source of a noweb file (specifically a generic) from the > > Target (e.g LINUXLIBC6) directory of the compiler to the src > > directory. In that way the compiler can use the source. The name of > > functions could be: "derived_generic_interface", > > "derived_generic_implementation"> >> > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/> > The literate programming support was present on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a look at all that stuff, even downloaded ldb and installed noweb.> Still, I'd need a simple example to understand what exactly you would> like to have included in CM3 by default. Just the four commented-out> noweb procedures from M3Build.m3? Or more elaborate stuff like that> included in the ldb distribution?> > Is there any problem with just including the 4 quake procedures as> template? Anything that would not work?> > If you could provide a simple m3 package which contains all the uses> you'd like to see supported, we could even use that as a regression> test add-on. So if you send me a more specific and exact definition> and example, I'll try to add everything that is needed.> > I've never done literate programming myself, and haven't got the time> to learn everything now and decide what is needed.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Feb 6 23:04:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 06 Feb 2008 14:04:43 -0800 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: Your message of "Wed, 06 Feb 2008 21:46:31 GMT." Message-ID: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Isn't Nelson's book "Systems Programming with Modula-3" to a large extent composed of literate programming (Threads interfaces, etc.)? Modula-3 has really cool literate programming support and it'd be a shame to lose it. Also m3browser does support the automatic cross referencing you're talking about. Last I checked it was a bit buggy. In my experience, one of the really nice things about Modula-3 when you write moderately large programs is actually that it's very easy to find out where a T is being used, without using any special tools (like m3browser). You just grep for the name of the interface where that T is defined, and that gives you a superset of all possible uses of T. Modula-3 doesn't have the nasty Javaism "import libm3.*;" Mika Jay writes: >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Modula-3 and quake both support writing comments already. :) >=20 >I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic. >To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think. >=20 >All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index. >=20 >I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor? >=20 >I'm just being obnoxious. >=20 > ...Jay > > > >> Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dab= >enavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake= > extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." enavidesd at yahoo.es>:> > > Hi Olaf:> > Is still possible to add Literate pro= >gramming support, I mean using > > several functions that are just a commen= >tary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.= >com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=3D1.8;c= >ontent-type=3Dtext%2Fplain> >> > Also there is a missing one on Built-in fu= >nctions, one that "copy" > > the derived source of a noweb file (specifical= >ly a generic) from the > > Target (e.g LINUXLIBC6) directory of the compile= >r to the src > > directory. In that way the compiler can use the source. Th= >e name of > > functions could be: "derived_generic_interface", > > "derived= >_generic_implementation"> >> > This stuff is used on ldb debugger : http://= >www.eecs.harvard.edu/nr/ldb/> > The literate programming support was presen= >t on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS= >/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a = >look at all that stuff, even downloaded ldb and installed noweb.> Still, I'= >d need a simple example to understand what exactly you would> like to have = >included in CM3 by default. Just the four commented-out> noweb procedures f= >rom M3Build.m3? Or more elaborate stuff like that> included in the ldb dist= >ribution?> > Is there any problem with just including the 4 quake procedure= >s as> template? Anything that would not work?> > If you could provide a sim= >ple m3 package which contains all the uses> you'd like to see supported, we= > could even use that as a regression> test add-on. So if you send me a more= > specific and exact definition> and example, I'll try to add everything tha= >t is needed.> > I've never done literate programming myself, and haven't go= >t the time> to learn everything now and decide what is needed.> > Olaf> -- = >> Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb= >=E4ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177= > 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf= >=FChrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlotten= >burg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Modula-3 and quake both support writing comments = >already. :)
> 
>I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic.
>To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think.
> 
>All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index.
> 
>I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor?
> 
>I'm just being obnoxious.
> 
> ...Jay


> >
>
>> Date: Wed, 6 Feb 2008 20:15:26 +0100
> From: wagner at elegosoft.co= >m
> To: dabenavidesd at yahoo.es
> CC: m3devel at elegosoft.com
&g= >t; Subject: Re: [M3devel] quake extensions for tests / RFC
>
>= > Quoting "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>:
= >>
> > Hi Olaf:
> > Is still possible to add Literate = >programming support, I mean using
> > several functions that are = >just a commentary at the end of the file
> > on M3Build.m3:
&g= >t; > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-s= >ys/cm3/src/M3Build.m3?rev=3D1.8;content-type=3Dtext%2Fplain
> >>> > Also there is a missing one on Built-in functions, one that "cop= >y"
> > the derived source of a noweb file (specifically a generic= >) from the
> > Target (e.g LINUXLIBC6) directory of the compiler = >to the src
> > directory. In that way the compiler can use the so= >urce. The name of
> > functions could be: "derived_generic_interf= >ace",
> > "derived_generic_implementation"
> >
> &= >gt; This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb= >/
> > The literate programming support was present on DEC SRC M3 I= > think:
> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA= >_3/html/modula-3/html/m3build/noweb.html
>
> Hi again,
>= >
> I've had a look at all that stuff, even downloaded ldb and instal= >led noweb.
> Still, I'd need a simple example to understand what exac= >tly you would
> like to have included in CM3 by default. Just the fou= >r commented-out
> noweb procedures from M3Build.m3? Or more elaborate= > stuff like that
> included in the ldb distribution?
>
>= > Is there any problem with just including the 4 quake procedures as
>= > template? Anything that would not work?
>
> If you could prov= >ide a simple m3 package which contains all the uses
> you'd like to s= >ee supported, we could even use that as a regression
> test add-on. S= >o if you send me a more specific and exact definition
> and example, = >I'll try to add everything that is needed.
>
> I've never done= > literate programming myself, and haven't got the time
> to learn eve= >rything now and decide what is needed.
>
> Olaf
> -- >> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-All= >ee 25 / Geb=E4ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 = >96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.eleg= >osoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelr= >egister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
&g= >t;


Connect and share in new ways with Windows Live. href=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharel= >ife_012008' target=3D'_new'>Get it now! >= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_-- From wagner at elegosoft.com Thu Feb 7 00:07:08 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 07 Feb 2008 00:07:08 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> References: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Message-ID: <20080207000708.380w844gg80cws0k@mail.elegosoft.com> Quoting Mika Nystrom : > Isn't Nelson's book "Systems Programming with Modula-3" to a large > extent composed of literate programming (Threads interfaces, etc.)? > Modula-3 has really cool literate programming support and it'd be > a shame to lose it. Also m3browser does support the automatic cross > referencing you're talking about. Last I checked it was a bit > buggy. Well, I think you're right and one can see m3browser as a kind of special literate programming support. And if it is currently buggy -- perhaps you could explain what exactly is wrong -- we should certainly fix it. However, I understood the request of Daniel Alejandro Benavides as one to re-add support for some generic literate programming tools which where already supported in earlier releases of M3. There is no harm in that, and I think we should be open for integrations of many such tools. I don't think it will be very difficult to add this support (as it has already been there), I'm just not familiar enough with the noweb tools to exactly know what is needed, so I asked for some help. I also think the SGML tools that were used for the PM3 documentation are a kind of literate programming support; and that's probably the most powerful and promising solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Feb 7 03:30:49 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 Feb 2008 03:30:49 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Feb 8 21:49:19 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 8 Feb 2008 21:49:19 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Message-ID: <32680.74034.qm@web27114.mail.ukl.yahoo.com> Hi: I'm sorry for not writing you all the things I like to see on CM3. It seems that the creator of ldb (Norman Ramsey) has been the creator of noweb, so I think his package as far as I have compiled it, is a good test, but maybe too large, so yes I would love to contribute with it. >Is there any problem with just including the 4 quake procedures as >template? Anything that would not work? There isn`t (I think I have compiled with those functions as a ldb-template package template on ldb), but the builtin procedure which I don't see is the one I wrote so I think it should be added in this text case of ldb but also in other cases (I think quake acts as a prepocessor of the noweb Modula-3/generic sources). Thanks again, and hope that I answeres better this time. "Daniel Alejandro Benavides D." escribi?: Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 9 18:52:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 09 Feb 2008 18:52:43 +0100 Subject: [M3devel] www.opencm3.net, m3tohtml and current CM3 source browser Message-ID: <20080209185243.kbm6grheyoks40g0@mail.elegosoft.com> After looking for some suitable domain names that are still available, Elego has secured www.opencm3.net to allow easier access to the CM3 project. http://www.opemcm3.net is now the same as http://modula3.elegosoft.com/cm3/ but shorter and probably easier to remember. Unfortunately www.opencm3.org and the shorter www.cm3.xxx domains are already owned by others. I've made a small update to m3tohtml and automated the HTML doc generation in cm3/scripts/regression/defs.sh:test_m3tohtml. This is now also run nightly on birch.elegosoft.com. Next to running m3browser directly on our web server, this seems the easiest way to allow browsing of all current sources. Have a look at http://www.opencm3.net/doc/help/gen_html/INDEX.html. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 10 10:28:22 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:28:22 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: "cross posting", guilty. (This might have something to do with NT386GNU CM3 hanging upon startup but I haven't figured out much..in CM3, nanosleep fails and I don't think ThreadPThread__SignalHandler is ever called, whereas here nanosleep succeeds and the signal handler is called at least a few times; I'm going to try some hack with the Cygwin nanosleep uses sleep instead or something...) From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 10 10:43:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:43:58 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: oh the burden of my own cross-posting.. - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: RE: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:43:20 +0000 Given that sleep is implemented via nanosleep in the obvious simple way..Still, any additional clues/explanations are welcome. :) - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sun Feb 10 22:55:01 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 10 Feb 2008 15:55:01 -0600 Subject: [M3devel] <*LAZYALIGN*> Message-ID: <47AF72B5.2080308@wichita.edu> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it being used anywhere? It is not documented in pragmas.html. The compiler front end appears to accept it. (In fact, Decls.m3 contains constants that suggest limitations on what declarations the pragma can appear on, but these are not actually enforced.) It liberalizes the alignment rules, generally allowing scalars to start on any byte boundary. Pickles have to be able to reconstruct the layout of types as the compiler would have done it for a machine (on which a now-being-read pickle was written) with different word size and alignment properties. Currently, pickles are completely unaware of lazy alignment. It would have to be encoded in type descriptions generated by the compiler using TipeDesc and read by pickles using RTTipe. Most troubling to me is what looks like a linguistic Pandora's box. The pragma can be associated with any constant, variable, or type _declaration_ (not type definition), with the result that different values of the same type can actually be different in their alignment rules and thus their layout. Similarly for different identifiers equated to the same type. Although the effects of this could possibly be hidden from the programmer in purely safe code, not so with unsafe code. I haven't thoroughly thought this through, but seems to me to really fly in the face of the whole typing philosophy of the language. For example, if pickles were to read in an object value, and there were >1 variants of the object's type in the reading program, differing only in the alignment rules, how would it decide which one to build? In fact, ignoring pickles altogether and just looking at a single program, if the object's type doesn't actually uniquely give its memory layout, how can it be accessed correctly? Additionally, a quick look at the compiler suggests it won't generate correct code for whole record assignment when the LHS and RHS are the same type but have different alignment characteristics. The more I think about it, it seems the only workable possibilities are: 1) Require the pragma to be associated only with a type _definition_ not a declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make this a property of the type that propagates to all names for the type and all variables, constants, etc. Also, this would make this property a part of the type signature that pickles uses when reading, -OR- 2) Forget it altogether. What do people think? -- ------------------------------------------------------------- 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 Mon Feb 11 10:15:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: <20080211091341.D290C10D4527@birch.elegosoft.com> References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:29:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:29:10 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080211092401.1068410D466B@birch.elegosoft.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: Does anyone else find it bothersome that you can't introduce VARs anywhere? Kind of like in C++? Ok, or if you grant that frame size doesn't matter THAT much, and the compiler might do stack packing anyway, you can move all your locals up top like typical C, but still, how about for the module initializer? Still it seems good to me to do manual stack packing since it is often so easy.. WITH helps, but only for "relative constants". It would be nice if the code below could have still loops until t0 != t1, but the repeat condition is outside the scope in which t1 is available. This feels quite lame.. - Jay > Date: Mon, 11 Feb 2008 10:24:00 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:24:00> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > Log message:> no need for globals here..> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:35:16 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:35:16 +0000 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 11 Feb 2008 09:15:50 +0000Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) )(Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 11 10:58:18 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 11 Feb 2008 01:58:18 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Mon, 11 Feb 2008 09:29:10 GMT." Message-ID: <200802110958.m1B9wJ9u035766@camembert.async.caltech.edu> Jay writes: >--_568f4bdf-b056-453b-9c29-b8dff8a8bb4c_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Does anyone else find it bothersome that you can't introduce VARs anywhere?= > Kind of like in C++? No. From jayk123 at hotmail.com Mon Feb 11 11:13:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:13:09 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? Message-ID: I know this won't be popular but... over in m3-db\odbc\src, there is POSIX and WIN32, and they are ALMOST identical. The differences are the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. In Win32 all the <*external*> pragmas have WINAPI. In Posix, they lack it. For this and other reasons, I suggest that all CM3 frontends accept but silentlyignore the Win32/x86 calling conventions in <*external*> pragmas,similar to what the non-x86 Windows compilers do. The other reasons would be the "FARPROC" warning that I already cleared up otherwise. And anything else minor that comes up. I know this won't be popular but I REALLY REALLY REALLY believe is the right thing.It is a small safe change that will allow a little more Modula-3 source portability. A similar suggestion would be to change the default calling convention in Modula-3,it would very possibly reduce code size, but is very very very much a breakingchange so probably can never happen.Better probably would be to a) add a switch for this b) extend the .m3exportsor whatnot files to indicate what switch was used. A "blanket pragma" might also be good, so that the various *.i3 files cansay just to assume __stdcall for the rest of the file instead of annotating each functions. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 11:20:59 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 11:20:59 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <1202725259.8543.22.camel@faramir.m3w.org> Why would we, when in M3 we can have blocks as statements? Isn't that a mechanism to localize scope even more? d On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and the > compiler might do stack packing anyway, you can move all your locals > up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is often > so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 != > t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > ______________________________________________________________________ > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > > ______________________________________________________________________ > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 11:34:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:34:19 +0000 Subject: [M3devel] __declspec(dllimport)? Message-ID: __declspec(dllimport) is a nice little cheap optimization on Windows. When you are calling a function that you will be dynamically linking to, it saves one instructions per call. On Windows, the way dynamic linking works is that for all your imports, there is one array of pointers in your .dll/.exe. It could actually be discontiguous. It is an array per .dll rather, with a terminal NULL for each .dll you import from. All the dynamic loader does is write pointers into this array at load time. It does not have to, like, go all through your code patching stuff up. If you just call Foo, but end up importing Foo, the linker generates a one instruction function: Foo: jmp dword ptr[__imp__Foo] __imp__Foo is in that array that gets patched up. However if you declare Foo to be __declspec(dllimport), the compiler will instead of: call Foo generate: call dword ptr[__imp__Foo] in fact, if you have multiple nearby calls to Foo, the compiler knows these pointers are "relatively const" and will fetch the pointer and hold it in a register and make the calls through the register. There is a problem with __declspec(dllimport). Essentially, you know, for every imported function Foo, there is somewhere out there someone implementing it. They are not importing it. They are exporting it. While getting this declaration wrong is actually "ok", it ends up costing the implementer an extra instruction on their calls, and generates a linker warning ("importing local function"). So what ends up happening usually is either a) the implementer doesn't #include his own header files, generally a bad bad bad idea or b) for every .dll bar.dll, a macro is made up BARAPI and then the code usually goes like: #ifndef BARAPI #define BARAPI __declspec(dllimport) #endif BARAPI void __stdcall Foo(void); and the implementer will define BARAPI to either be nothing/empty, or __declspec(dllexport). (__declspec(dllexport) is another topic, I'll try not to go into here.) This is a little gross, this proliferation of "cover" macros for __declspec(dllimport). But it IS a nice little optimization. Actually I suspect many people think these annotations are required. But they almost never ever are. But they are nice to have. So, what do people think? Worth some syntax? In <*extern*> pragmas? Gcc already understand this stuff I believe. I think I noticed it when looking at the __stdcall stuff. Another wrinkle here is that Modula-3 has this nice build_standalone() feature, which switches whether or not you dynamically link. It would tend to invalidate statements here, at least about Modula-3 code. On the matter of when __declspec(dllimport) is needed. - I'm not sure about C++ classes. You should just never import then really, but use COM instead, but people do. (COM is just using pure virtual function calls -- ie: calls through structs containing all function pointers, and get a pointer to said struct via a special C creation function). - It is needed for data, at least with Microsoft tools. The GNU tools seem to have some workaround here. Notice I pointed out the linker generates a function for you if you don't make the annotation. You can't intervene on data accesses with a function call, unless, say, you've inserted a function call for every single data access, or if you can still go back and change the code, like at link time. Data imports are rare and I suggest just never use them. But they are much faster when they suffice, true. __declspec(dllexport) can generally just be replaced with a .def file. - again, I don't know about C++ classes - for C++ functions, the .def file will contain some ugly processor-specific mangled names, a little bit difficult/annoying to come up with and put in the .def file, but not impossible by far (link /dump /symbols | findstr /v UNDEF for example) - again, just don't export C++ classes, or mangled/overloaded/etc. names, only export C functions and you are set with a .def file; this also aids compatibility with multiple compilers and languages (!) - (C++ is largely well and good and I can tell you what is good about it, but one thing it is NOT good for is defining dynamically linked interfaces; I think Modula-3 can get into the same trap -- e.g. traffic only in a few base types (integer, text) and opaque types, don't let dynamically linked callers know about your record format/offsets, else you'll have to recompile "too often") __declspec(dllexport) provides no optimization analogous to __declspec(dllimport). - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 11:36:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:36:19 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: Could be my ignorance of Modula-3 then..let me try a bit more.. - Jay > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 11:20:59 +0100> > Why would we, when in M3 we can have blocks as statements? Isn't that a> mechanism to localize scope even more?> > d> > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > Does anyone else find it bothersome that you can't introduce VARs> > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and the> > compiler might do stack packing anyway, you can move all your locals> > up top like typical C, but still, how about for the module> > initializer?> > Still it seems good to me to do manual stack packing since it is often> > so easy..> > WITH helps, but only for "relative constants".> > > > It would be nice if the code below could have still loops until t0 !=> > t1, but the repeat condition is outside the scope in which t1 is> > available. This feels quite lame..> > > > - Jay> > > > > > > > ______________________________________________________________________> > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > > > > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message:> > > no need for globals here..> > > > > > > > > > > ______________________________________________________________________> > Helping your favorite cause is as easy as instant messaging. You IM,> > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 12:04:09 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 12:04:09 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <1202727849.8543.24.camel@faramir.m3w.org> A piece of code, from the middle of somewhere... len:=Wr.Length(swr.wr); data := TextWr.ToText(swr.wr); VAR s: Ctypes.char_star := M3toC.CopyTtoS(data); ff: ADDRESS := LOOPHOLE(s, ADDRESS); a: UNTRACED REF CHAR; spent: CARDINAL := 0; checkSum: Word.T := 0; BEGIN a := ff; WITH sum = NEW(Sumator) DO sum.reset(); > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote: > Why would we, when in M3 we can have blocks as statements? Isn't that a > mechanism to localize scope even more? > > d > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++? > > Ok, or if you grant that frame size doesn't matter THAT much, and the > > compiler might do stack packing anyway, you can move all your locals > > up top like typical C, but still, how about for the module > > initializer? > > Still it seems good to me to do manual stack packing since it is often > > so easy.. > > WITH helps, but only for "relative constants". > > > > It would be nice if the code below could have still loops until t0 != > > t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame.. > > > > - Jay > > > > > > > > ______________________________________________________________________ > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > To: m3commit at elegosoft.com > > > From: jkrell at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message: > > > no need for globals here.. > > > > > > > > > > > ______________________________________________________________________ > > Helping your favorite cause is as easy as instant messaging. You IM, > > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 12:23:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:23:18 +0000 Subject: [M3devel] size_t? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = INTEGER; really? it is signed? and we are sure this is going to be 64 bits on 64 bit targets? size_t and ptrdiff_t ought to be in BasicCtypes, right?That has a 32 bit and 64 bit version, at least. Does INTEGER effectively equal int or ptrdiff_t? - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 12:28:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:28:01 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202727849.8543.24.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <1202727849.8543.24.camel@faramir.m3w.org> Message-ID: ok thanks, done > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 12:04:09 +0100> > A piece of code, from the middle of somewhere...> > len:=Wr.Length(swr.wr);> data := TextWr.ToText(swr.wr);> VAR> s: Ctypes.char_star := M3toC.CopyTtoS(data);> ff: ADDRESS := LOOPHOLE(s, ADDRESS);> a: UNTRACED REF CHAR;> > spent: CARDINAL := 0;> checkSum: Word.T := 0;> BEGIN> a := ff;> WITH sum = NEW(Sumator) DO> sum.reset();> > > > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote:> > Why would we, when in M3 we can have blocks as statements? Isn't that a> > mechanism to localize scope even more?> > > > d> > > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs> > > anywhere? Kind of like in C++?> > > Ok, or if you grant that frame size doesn't matter THAT much, and the> > > compiler might do stack packing anyway, you can move all your locals> > > up top like typical C, but still, how about for the module> > > initializer?> > > Still it seems good to me to do manual stack packing since it is often> > > so easy..> > > WITH helps, but only for "relative constants".> > > > > > It would be nice if the code below could have still loops until t0 !=> > > t1, but the repeat condition is outside the scope in which t1 is> > > available. This feels quite lame..> > > > > > - Jay> > > > > > > > > > > > ______________________________________________________________________> > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > > To: m3commit at elegosoft.com> > > > From: jkrell at elego.de> > > > Subject: [M3commit] CVS Update: cm3> > > > > > > > CVSROOT: /usr/cvs> > > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > > > Modified files:> > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message:> > > > no need for globals here..> > > > > > > > > > > > > > > > ______________________________________________________________________> > > Helping your favorite cause is as easy as instant messaging. You IM,> > > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 12:30:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 12:30:37 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Quoting Jay : > I know this won't be popular but... > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > The differences are > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > For this and other reasons, I suggest that all CM3 frontends accept > but silentlyignore the Win32/x86 calling conventions in <*external*> > pragmas,similar to what the non-x86 Windows compilers do. > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing.It is a small safe change that will allow a little > more Modula-3 source portability. If I understand you correctly, you'd like to declare the external procedures as WINAPI in general and let all backends except the Windows one ignore it. We should not call it WINAPI then, I think; what about SYSAPI as a general abstraction? > A similar suggestion would be to change the default calling > convention in Modula-3,it would very possibly reduce code size, but > is very very very much a breakingchange so probably can never > happen.Better probably would be to a) add a switch for this b) > extend the .m3exportsor whatnot files to indicate what switch was > used. We shouldn't change the default calling conventions. That is, we should check very very carefully if there are negative effects of doing this and how we cope with them. Until this has been done, we shouldn't change the default calling conventions :-) > A "blanket pragma" might also be good, so that the various *.i3 > files cansay just to assume __stdcall for the rest of the file > instead of annotating each functions. You're talking about a pragma default for all declarations in a file, aren't you? I wouldn't object to that, but it would probably need some compiler extensions, wouldn't 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 Mon Feb 11 13:41:39 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:41:39 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: Olaf, yes you understand me. I strongly object to calling it SYSAPI however, or pretty much any attempt at further abstraction here. I would consider some sort of qualifier that says when to pay attention, when to ignore. For example using a platform name, <*external NT386:WINAPI*>. This is edging toward "preprocessing" but an incredibly small step. (Even though a big problem with preprocessing is rampant context sensitivity, sensitivity to what the target is, and reparsing for every target, is reasonable, and is how M3 already works.) It isn't the "system" calling convention really, it is just very commonly used by the "OS". The "OS" is just a bunch of .dlls, and many of them happen to use __stdcall aka WINAPI a lot, but not all, and not for all functions. "system" MIGHT be how you call the kernel, but that is different. (calling the kernel is not directly exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). msvcrt.dll uses __cdecl for the most part. Anything that accepts varargs, which is very few functions, uses __cdecl, out of necessity (at least give a "normal" point of view, I did used to use a system where calleee popped varargs...). If you write drivers, a small number of functions are __fastcall. I would rather drop the synonyms and just have __cdecl, __fastcall, __stdcall, than to invent "SYSAPI". However I don't really want to do that, "WINAPI" and the other names are useful for a more literal translation of headers. There is a mix of calling conventions on x86 Windows and there is not really one "SYSAPI". The negative affects of changing the default calling convention is breaking all existing dynamic links where you only rebuild one side and where the calling convention wasn't explicit (all of them). Very very bad. > you'd like to declare the external procedures as WINAPI in general Not quite in general perhaps. But I guess any file for which someone has portable C and it is built for NT386 and anything else. Explicit calling conventions are always reasonable on NT386 and never reasonable anywhere else. The Visual C++ compiler has a command line switch as to what the default calling convention is, and widely used headers should work no matter what is the default. - Jay > Date: Mon, 11 Feb 2008 12:30:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > > I know this won't be popular but...> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> > The differences are> > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed.> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> > For this and other reasons, I suggest that all CM3 frontends accept > > but silentlyignore the Win32/x86 calling conventions in <*external*> > > pragmas,similar to what the non-x86 Windows compilers do.> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.It is a small safe change that will allow a little > > more Modula-3 source portability.> > If I understand you correctly, you'd like to declare the external> procedures as WINAPI in general and let all backends except the> Windows one ignore it. We should not call it WINAPI then, I think;> what about SYSAPI as a general abstraction?> > > A similar suggestion would be to change the default calling > > convention in Modula-3,it would very possibly reduce code size, but > > is very very very much a breakingchange so probably can never > > happen.Better probably would be to a) add a switch for this b) > > extend the .m3exportsor whatnot files to indicate what switch was > > used.> > We shouldn't change the default calling conventions. That is, we should> check very very carefully if there are negative effects of doing this> and how we cope with them.> Until this has been done, we shouldn't change the default calling> conventions :-)> > > A "blanket pragma" might also be good, so that the various *.i3 > > files cansay just to assume __stdcall for the rest of the file > > instead of annotating each functions.> > You're talking about a pragma default for all declarations in a> file, aren't you? I wouldn't object to that, but it would> probably need some compiler extensions, wouldn't 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> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 13:48:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:48:23 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211111256.22C8E10D4628@birch.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: Here is another SMALL gripe with the language. The need to put IMPORTS at the top (or is it just common style?), leads to something I have seen several times. You comment out some code, thereby deleting the only/last use of some import, that nets you warnings about unused imports. Granted, they are "only" warnings, but I try to have none. Also granted, you can either comment out or just go ahead and remove the imports, easy. It might be nice if the IMPORTS could be adjacent to the code using the IMPORTS, so that they can be comment out or removed together. This "problem" is not unique to Modula-3, by far. In fact, Modula-3 is probably more able to warn about this low cost waste due to its much better module system, compared to say, C and C++ #includes... - Jay > Date: Mon, 11 Feb 2008 12:12:56 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 12:12:56> > Modified files:> cm3/m3-ui/ui/src/winvbt/: WinScreenType.m3 > > Log message:> fix warning about unused import (the use is commented out..would be nice> to be able to move the import to near the code so they can be commented> out together..)> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 14:12:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:12:03 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Quoting Jay : > Olaf, yes you understand me. > > I strongly object to calling it SYSAPI however, or pretty much any > attempt at further abstraction here. > > I would consider some sort of qualifier that says when to pay > attention, when to ignore. > For example using a platform name, <*external NT386:WINAPI*>. > This is edging toward "preprocessing" but an incredibly small step. > (Even though a big problem with preprocessing is rampant context > sensitivity, sensitivity to what the target is, and reparsing for > every target, is reasonable, and is how M3 already works.) > > It isn't the "system" calling convention really, it is just very > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > many of them happen to use __stdcall aka WINAPI a lot, but not all, > and not for all functions. "system" MIGHT be how you call the > kernel, but that is different. (calling the kernel is not directly > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). OK, so it's not system specific, but its system specific that there are multiple calling conventions for Windows. However, I'm still not convinced that this may affect only Windows systems and no others. It may sound academic, but wouldn't it be possible that suddenly Apple (or even some new OS player :) comes up with similar distinctions? I think we shouldn't implement a pragma convention that is usable only for Windows, but one that is more generic. If we can just extend your example to something like <*EXTERNAL NT386:WINAPI, ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> this would be better. As for the semantic differences on different target platforms, I think we could live with them given that all this stuff is system dependent and unsafe anyway, but I'd like to hear the opinion of others on this topic, too. Olaf > msvcrt.dll uses __cdecl for the most part. > Anything that accepts varargs, which is very few functions, uses > __cdecl, out of necessity (at least give a "normal" point of view, I > did used to use a system where calleee popped varargs...). > If you write drivers, a small number of functions are __fastcall. > I would rather drop the synonyms and just have __cdecl, __fastcall, > __stdcall, than to invent "SYSAPI". > However I don't really want to do that, "WINAPI" and the other names > are useful for a more literal translation of headers. > There is a mix of calling conventions on x86 Windows and there is > not really one "SYSAPI". > > The negative affects of changing the default calling convention is > breaking all existing dynamic links where you only rebuild one side > and where the calling convention wasn't explicit (all of them). Very > very bad. > > > you'd like to declare the external procedures as WINAPI in general > > Not quite in general perhaps. > But I guess any file for which someone has portable C and it is > built for NT386 and anything else. > Explicit calling conventions are always reasonable on NT386 and > never reasonable anywhere else. > The Visual C++ compiler has a command line switch as to what the > default calling convention is, and widely used headers should work > no matter what is the default. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 11 14:17:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:17:56 +0100 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Quoting Jay : > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and > C++ #includes.. I wouldn't like to see any changes here. It is good that all the imports are explicit, and it is good that they are at the top (to define the dependencies). It's not much effort to add or remove an import for debugging etc. If you are really lazy, you can always use the NOWARN pragma: IMPOPRT IO <*NOWARN*> to suppres the warnings for that declaration. That was not your point though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Feb 11 14:31:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:31:41 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: I don't think anyone else will commit the error of having multiple calling conventions. It's a bad place to be. Granted, kernels often do have an unusual calling convention, but that gets wrapped up in something "normal". > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> In practice this will only ever be: > <*EXTERNAL NT386:WINAPI *> and I am satisfied. :) oh, btw, the other obvious: > <*NT386:EXTERNAL WINAPI *> or even in general both -- pragms can all be prefixed with a platform. In practise, "external" is platform-independent, calling convention is not. There might be exceptions, where particular platforms require a Modula-3 wrapper. As Cygwin had briefly for semaphore initialization. I guess this really does in general resemble preprocessing, only by target, only of pragmas, and the point really is to limit per-platform branching when the platforms are indeed extremely similar. This is a common pattern -- if'ing stuff midly, if'ing stuff to heck, vs. splitting out in separate implementation with no ugly if'ing. OpenGL is in a similar boat here, except that it seems to be a disproof. It appears the Cygwin/X OpenGL functions use __cdecl while the Microsoft ones use __stdcall. Again the *.i3 files are almost the same, except for calling conventions, but it seems the "NT386 POSIX" variant uses a different calling convention than the "NT386 WIN32" variant. I am not 100% what is going on in OpenGL. Building "std" for NT386GNU gets at least as far as anim3d, however I haven't run much of the code at all -- only enough of cm3 to see it has a problem with paths... I'm still just using a "regular" NT386 in a sort of cross scenario. - Jay > Date: Mon, 11 Feb 2008 14:12:03 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > Olaf, yes you understand me.> >> > I strongly object to calling it SYSAPI however, or pretty much any > > attempt at further abstraction here.> >> > I would consider some sort of qualifier that says when to pay > > attention, when to ignore.> > For example using a platform name, <*external NT386:WINAPI*>.> > This is edging toward "preprocessing" but an incredibly small step.> > (Even though a big problem with preprocessing is rampant context > > sensitivity, sensitivity to what the target is, and reparsing for > > every target, is reasonable, and is how M3 already works.)> >> > It isn't the "system" calling convention really, it is just very > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > many of them happen to use __stdcall aka WINAPI a lot, but not all, > > and not for all functions. "system" MIGHT be how you call the > > kernel, but that is different. (calling the kernel is not directly > > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is).> > OK, so it's not system specific, but its system specific that there> are multiple calling conventions for Windows. However, I'm still not> convinced that this may affect only Windows systems and no others.> It may sound academic, but wouldn't it be possible that suddenly> Apple (or even some new OS player :) comes up with similar distinctions?> > I think we shouldn't implement a pragma convention that is usable> only for Windows, but one that is more generic. If we can just> extend your example to something like> > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*>> > this would be better.> > As for the semantic differences on different target platforms, I think> we could live with them given that all this stuff is system dependent> and unsafe anyway, but I'd like to hear the opinion of others on this> topic, too.> > Olaf> > > msvcrt.dll uses __cdecl for the most part.> > Anything that accepts varargs, which is very few functions, uses > > __cdecl, out of necessity (at least give a "normal" point of view, I > > did used to use a system where calleee popped varargs...).> > If you write drivers, a small number of functions are __fastcall.> > I would rather drop the synonyms and just have __cdecl, __fastcall, > > __stdcall, than to invent "SYSAPI".> > However I don't really want to do that, "WINAPI" and the other names > > are useful for a more literal translation of headers.> > There is a mix of calling conventions on x86 Windows and there is > > not really one "SYSAPI".> >> > The negative affects of changing the default calling convention is > > breaking all existing dynamic links where you only rebuild one side > > and where the calling convention wasn't explicit (all of them). Very > > very bad.> >> > > you'd like to declare the external procedures as WINAPI in general> >> > Not quite in general perhaps.> > But I guess any file for which someone has portable C and it is > > built for NT386 and anything else.> > Explicit calling conventions are always reasonable on NT386 and > > never reasonable anywhere else.> > The Visual C++ compiler has a command line switch as to what the > > default calling convention is, and widely used headers should work > > no matter what is the default.> > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 14:33:42 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:33:42 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Message-ID: > If you are really lazy, you can always use the NOWARN pragma: What if I am really really really lazy? :) > I wouldn't like to see any changes here. ok. - Jay > Date: Mon, 11 Feb 2008 14:17:56 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] imports anywhere?> > Quoting Jay :> > > Here is another SMALL gripe with the language.> > The need to put IMPORTS at the top (or is it just common style?), > > leads to something I have seen several times.> > You comment out some code, thereby deleting the only/last use of > > some import, that nets you warnings about unused imports. Granted, > > they are "only" warnings, but I try to have none. Also granted, you > > can either comment out or just go ahead and remove the imports, easy.> >> > It might be nice if the IMPORTS could be adjacent to the code using > > the IMPORTS, so that they can be comment out or removed together.> >> > This "problem" is not unique to Modula-3, by far.> > In fact, Modula-3 is probably more able to warn about this low cost > > waste due to its much better module system, compared to say, C and > > C++ #includes..> > I wouldn't like to see any changes here.> > It is good that all the imports are explicit, and it is good that> they are at the top (to define the dependencies). It's not much> effort to add or remove an import for debugging etc.> > If you are really lazy, you can always use the NOWARN pragma:> > IMPOPRT IO <*NOWARN*>> > to suppres the warnings for that declaration. That was not your> point though.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 15:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 14:38:14 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211142730.E6B3A10D4655@birch.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: It'd be nice if I could declare externals in modules. In this example, setitimer_ only exists for the wrapper implementation. I don't need it to be visible outside the one module that uses it. I guess I could push it into an unexposed interface, even dedicate "internal.i3" to it?Is that an ok idiom? It's another problem that I don't know what to call these things.. - Jay > Date: Mon, 11 Feb 2008 15:27:30 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 15:27:30> > Modified files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 m3makefile > Added files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.m3 > > Log message:> make setitimer(ITIMER_VIRTUAL) always succeed, even though Cygwin> would always fail it (not so accurate a Unix emulation eh?)> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 16:02:40 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 16:02:40 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Quoting Jay : > It'd be nice if I could declare externals in modules. > In this example, setitimer_ only exists for the wrapper implementation. > I don't need it to be visible outside the one module that uses it. > I guess I could push it into an unexposed interface, even dedicate > "internal.i3" to it?Is that an ok idiom? Yes, use an internal interface of the package. But you should use another name (something longer and more unique), since the CM3 builder still has problems with multiple defined units AFAIK. This is something that should really be fixed, but that's another topic. (We'd need hierarchical name spaces, but introduce them in a compatible way.) Olaf > It's another problem that I don't know what to call these things.. This usually is _my_ problem :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 11 17:23:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:23:47 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: Message-ID: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Do we know that this actually results in any real performance improvement. On Feb 11, 2008, at 5:34 AM, Jay wrote: > __declspec(dllimport) is a nice little cheap optimization on Windows. > When you are calling a function that you will be dynamically > linking to, it saves one instructions per call. > > On Windows, the way dynamic linking works is that for all your > imports, there is one array of pointers in your .dll/.exe. > It could actually be discontiguous. It is an array per .dll rather, > with a terminal NULL for each .dll you import from. All the dynamic > loader does is write pointers into this array at load time. It does > not have to, like, go all through your code patching stuff up. > > If you just call Foo, but end up importing Foo, the linker > generates a one instruction function: > Foo: > jmp dword ptr[__imp__Foo] > > __imp__Foo is in that array that gets patched up. > > However if you declare Foo to be __declspec(dllimport), the > compiler will instead of: > call Foo > generate: > call dword ptr[__imp__Foo] > > in fact, if you have multiple nearby calls to Foo, the compiler > knows these pointers are "relatively const" and will fetch the > pointer and hold it in a register and make the calls through the > register. > > There is a problem with __declspec(dllimport). > Essentially, you know, for every imported function Foo, there is > somewhere out there someone implementing it. > They are not importing it. They are exporting it. > While getting this declaration wrong is actually "ok", it ends up > costing the implementer an extra instruction on their calls, and > generates a linker warning ("importing local function"). > > So what ends up happening usually is either a) the implementer > doesn't #include his own header files, generally a bad bad bad idea > or b) for every .dll bar.dll, a macro is made up BARAPI and then > the code usually goes like: > > #ifndef BARAPI > #define BARAPI __declspec(dllimport) > #endif > > BARAPI void __stdcall Foo(void); > > and the implementer will define BARAPI to either be nothing/empty, > or __declspec(dllexport). > (__declspec(dllexport) is another topic, I'll try not to go into > here.) > > This is a little gross, this proliferation of "cover" macros for > __declspec(dllimport). > But it IS a nice little optimization. > Actually I suspect many people think these annotations are required. > But they almost never ever are. But they are nice to have. > > So, what do people think? > Worth some syntax? In <*extern*> pragmas? > Gcc already understand this stuff I believe. > I think I noticed it when looking at the __stdcall stuff. > > Another wrinkle here is that Modula-3 has this nice build_standalone > () feature, which switches whether or not you dynamically link. It > would tend to invalidate statements here, at least about Modula-3 > code. > > On the matter of when __declspec(dllimport) is needed. > - I'm not sure about C++ classes. You should just never import > then really, but use COM instead, but people do. > (COM is just using pure virtual function calls -- ie: calls > through structs containing all function pointers, and get a pointer > to said struct via a special C creation function). > > - It is needed for data, at least with Microsoft tools. The GNU > tools seem to have some workaround here. > Notice I pointed out the linker generates a function for you if > you don't make the annotation. You can't intervene on data accesses > with a function call, unless, say, you've inserted a function call > for every single data access, or if you can still go back and > change the code, like at link time. Data imports are rare and I > suggest just never use them. But they are much faster when they > suffice, true. > > __declspec(dllexport) can generally just be replaced with a .def file. > - again, I don't know about C++ classes > - for C++ functions, the .def file will contain some ugly > processor-specific mangled names, a little bit difficult/annoying > to come up with and put in the .def file, but not impossible by far > (link /dump /symbols | findstr /v UNDEF for example) > - again, just don't export C++ classes, or mangled/overloaded/ > etc. names, only export C functions and you are set with a .def > file; this also aids compatibility with multiple compilers and > languages (!) > - (C++ is largely well and good and I can tell you what is good > about it, but one thing it is NOT good for is defining dynamically > linked interfaces; I think Modula-3 can get into the same trap -- > e.g. traffic only in a few base types (integer, text) and opaque > types, don't let dynamically linked callers know about your record > format/offsets, else you'll have to recompile "too often") > > __declspec(dllexport) provides no optimization analogous to > __declspec(dllimport). > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Feb 11 17:26:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:26:50 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: Why not simply default EXTERNAL on Win32 to WINAPI instead? That way, all EXTERNALs will look the same but you won't clutter up non- Win32 with ugly WINAPI. On Feb 11, 2008, at 5:13 AM, Jay wrote: > I know this won't be popular but... > > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > > The differences are > > the UNUSED type SQLHWND is ADDRESS or HWND > This should just be removed. > > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > > For this and other reasons, I suggest that all CM3 frontends accept > but silently > ignore the Win32/x86 calling conventions in <*external*> pragmas, > similar to what the non-x86 Windows compilers do. > > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing. > It is a small safe change that will allow a little more Modula-3 > source portability. > > A similar suggestion would be to change the default calling > convention in Modula-3, > it would very possibly reduce code size, but is very very very much > a breaking > change so probably can never happen. > Better probably would be to a) add a switch for this b) extend > the .m3exports > or whatnot files to indicate what switch was used. > > A "blanket pragma" might also be good, so that the various *.i3 > files can > say just to assume __stdcall for the rest of the file instead of > annotating each functions. > > - Jay > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:28:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:28:56 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: <38355684-DFFB-43B0-81D9-D6745EA195BB@cs.purdue.edu> On Feb 11, 2008, at 8:31 AM, Jay wrote: > I don't think anyone else will commit the error of having multiple > calling conventions. > It's a bad place to be. > Granted, kernels often do have an unusual calling convention, but > that gets wrapped up in something "normal". > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > In practice this will only ever be: > > > <*EXTERNAL NT386:WINAPI *> I can live with this. > > > and I am satisfied. :) > > oh, btw, the other obvious: > > <*NT386:EXTERNAL WINAPI *> > > or even in general both -- pragms can all be prefixed with a platform. > In practise, "external" is platform-independent, calling convention > is not. > > There might be exceptions, where particular platforms require a > Modula-3 wrapper. As Cygwin had briefly for semaphore > initialization. I guess this really does in general resemble > preprocessing, only by target, only of pragmas, and the point > really is to limit per-platform branching when the platforms are > indeed extremely similar. > > This is a common pattern -- if'ing stuff midly, if'ing stuff to > heck, vs. splitting out in separate implementation with no ugly > if'ing. > > OpenGL is in a similar boat here, except that it seems to be a > disproof. > It appears the Cygwin/X OpenGL functions use __cdecl while the > Microsoft ones use __stdcall. > Again the *.i3 files are almost the same, except for calling > conventions, but it seems the "NT386 POSIX" variant uses a > different calling convention than the "NT386 WIN32" variant. > > I am not 100% what is going on in OpenGL. Building "std" for > NT386GNU gets at least as far as anim3d, however I haven't run much > of the code at all -- only enough of cm3 to see it has a problem > with paths... I'm still just using a "regular" NT386 in a sort of > cross scenario. > > - Jay > > > > Date: Mon, 11 Feb 2008 14:12:03 +0100 > > From: wagner at elegosoft.com > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] <*external winapi*> silently ignored on > all platforms? > > > > Quoting Jay : > > > Olaf, yes you understand me. > > > > > > I strongly object to calling it SYSAPI however, or pretty much any > > > attempt at further abstraction here. > > > > > > I would consider some sort of qualifier that says when to pay > > > attention, when to ignore. > > > For example using a platform name, <*external NT386:WINAPI*>. > > > This is edging toward "preprocessing" but an incredibly small > step. > > > (Even though a big problem with preprocessing is rampant context > > > sensitivity, sensitivity to what the target is, and reparsing for > > > every target, is reasonable, and is how M3 already works.) > > > > > > It isn't the "system" calling convention really, it is just very > > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > > many of them happen to use __stdcall aka WINAPI a lot, but not > all, > > > and not for all functions. "system" MIGHT be how you call the > > > kernel, but that is different. (calling the kernel is not directly > > > exposed in Win32, "kernel32.dll" is not the kernel, > ntoskrnl.exe is). > > > > OK, so it's not system specific, but its system specific that there > > are multiple calling conventions for Windows. However, I'm still not > > convinced that this may affect only Windows systems and no others. > > It may sound academic, but wouldn't it be possible that suddenly > > Apple (or even some new OS player :) comes up with similar > distinctions? > > > > I think we shouldn't implement a pragma convention that is usable > > only for Windows, but one that is more generic. If we can just > > extend your example to something like > > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > > > this would be better. > > > > As for the semantic differences on different target platforms, I > think > > we could live with them given that all this stuff is system > dependent > > and unsafe anyway, but I'd like to hear the opinion of others on > this > > topic, too. > > > > Olaf > > > > > msvcrt.dll uses __cdecl for the most part. > > > Anything that accepts varargs, which is very few functions, uses > > > __cdecl, out of necessity (at least give a "normal" point of > view, I > > > did used to use a system where calleee popped varargs...). > > > If you write drivers, a small number of functions are __fastcall. > > > I would rather drop the synonyms and just have __cdecl, > __fastcall, > > > __stdcall, than to invent "SYSAPI". > > > However I don't really want to do that, "WINAPI" and the other > names > > > are useful for a more literal translation of headers. > > > There is a mix of calling conventions on x86 Windows and there is > > > not really one "SYSAPI". > > > > > > The negative affects of changing the default calling convention is > > > breaking all existing dynamic links where you only rebuild one > side > > > and where the calling convention wasn't explicit (all of them). > Very > > > very bad. > > > > > > > you'd like to declare the external procedures as WINAPI in > general > > > > > > Not quite in general perhaps. > > > But I guess any file for which someone has portable C and it is > > > built for NT386 and anything else. > > > Explicit calling conventions are always reasonable on NT386 and > > > never reasonable anywhere else. > > > The Visual C++ compiler has a command line switch as to what the > > > default calling convention is, and widely used headers should work > > > no matter what is the default. > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:33:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:33:07 -0500 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <8B8213B4-3DBF-47CE-BC3E-1EE96B5F43F6@cs.purdue.edu> On Feb 11, 2008, at 4:15 AM, Jay wrote: > Aren't we better off with more VAR parameters and fewer UNTRACED REFs? > That way more interfaces/modules can be "safe", as this one changed? Indeed! I agree. > > > (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) > (Maybe a "DJGPP" target will satisfy? :) ) I barely care about Windows :-), whatever version you choose. > > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:13:41 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:13:41 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > > > Log message: > > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > > instead of GetSystemTime + SystemTimeToFileTime > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:34:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:34:54 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> You can, except you need to explicitly give the block scope: VAR ... BEGIN ... END; I find this much better than C++ where the scope of the new variable is imprecisely defined. On Feb 11, 2008, at 4:29 AM, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and > the compiler might do stack packing anyway, you can move all your > locals up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is > often so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 ! > = t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:38:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:38:48 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> On Feb 11, 2008, at 6:23 AM, Jay wrote: > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > INTEGER; > > really? it is signed? > and we are sure this is going to be 64 bits on 64 bit targets? > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > That has a 32 bit and 64 bit version, at least. These are OS-dependent! They should not be in BasicCtypes. > > > Does INTEGER effectively equal int or ptrdiff_t? > > - Jay > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:40:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:40:11 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: I hate imports that are scattered throughout since it hides dependencies deep in the guts of the code. Much better to have them explicit at the top! On Feb 11, 2008, at 7:48 AM, Jay wrote: > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and C > ++ #includes.. From hosking at cs.purdue.edu Mon Feb 11 17:41:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:41:24 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: Please -- no hierarchical namespaces. Ultimately, they need a definitive hierarchy anyway. On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > Quoting Jay : > >> It'd be nice if I could declare externals in modules. >> In this example, setitimer_ only exists for the wrapper >> implementation. >> I don't need it to be visible outside the one module that uses it. >> I guess I could push it into an unexposed interface, even >> dedicate "internal.i3" to it?Is that an ok idiom? > > Yes, use an internal interface of the package. But you should use > another name (something longer and more unique), since the CM3 > builder still has problems with multiple defined units AFAIK. > > This is something that should really be fixed, but that's another > topic. (We'd need hierarchical name spaces, but introduce them in > a compatible way.) > > Olaf > >> It's another problem that I don't know what to call these things.. > > This usually is _my_ problem :-) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Mon Feb 11 17:42:00 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:42:00 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Message-ID: <20080211164200.GB20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: > Do we know that this actually results in any real performance > improvement. Not clear -- hardware is getting pretty clever at doing at run-time the things that compilers used to sweat blood doing at compile time. I suspect that with fetch-and-branch-predictiong processors, the difference may unmeasurable. -- hendrik From hendrik at topoi.pooq.com Mon Feb 11 17:50:54 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:50:54 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211165054.GC20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:40:11AM -0500, Tony Hosking wrote: > I hate imports that are scattered throughout since it hides > dependencies deep in the guts of the code. Much better to have them > explicit at the top! > > On Feb 11, 2008, at 7:48 AM, Jay wrote: > > >Here is another SMALL gripe with the language. > >The need to put IMPORTS at the top (or is it just common style?), > >leads to something I have seen several times. > >You comment out some code, thereby deleting the only/last use of > >some import, that nets you warnings about unused imports. Granted, > >they are "only" warnings, but I try to have none. Also granted, you > >can either comment out or just go ahead and remove the imports, easy. > > > >It might be nice if the IMPORTS could be adjacent to the code using > >the IMPORTS, so that they can be comment out or removed together. > > > >This "problem" is not unique to Modula-3, by far. > >In fact, Modula-3 is probably more able to warn about this low cost > >waste due to its much better module system, compared to say, C and C > >++ #includes.. > I don't know if this is still the case, but long long ago, when I was reading the OS/2 port of Modula 3, there seemed to be an early phase that determined which source files had to be compiled. It could determine this from just the beginnings of the source files, and did not have to do full-scale Modula 3 parsing. I thought it a clever engineering trick. -- hendrik From rcoleburn at scires.com Mon Feb 11 17:58:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 11 Feb 2008 11:58:15 -0500 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <47B03853.1E75.00D7.1@scires.com> Jay: Not sure exactly what you are doing and how my answer will impact what you are doing, but here is my 2 cents. If there is stuff out there to deal with these old computers, we shouldn't remove it just because they are old. I still have Modula-3 code that is running on old computers. Indeed, the government tends to have some interesting requirements to keep alive certain systems that use old technology. I have delivered many systems over the course of my career whose actual lifetime was much longer than what anyone projected in the beginning. If we remove support for the old stuff, then we shoot ourselves in the foot for any type of support on these old systems. Indeed, I've recently been approached about making some changes to a system that I first developed back in the late 1990's. It is still around and working. One of the system components has been upgraded and they want me to make software changes to let the Modula-3 code work with the new component. This software controls and monitors satellite radio communications systems. Regards, Randy >>> Jay 2/11/2008 4:35 AM >>> ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs? That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/11 10:13:41 > > Modified files: > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message: > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > instead of GetSystemTime + SystemTimeToFileTime > Need to know the score, the latest news, or you need your Hotmail*-get your "fix". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) Climb to the top of the charts! Play the word scramble challenge with star power. Play now! ( http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 17:59:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:59:40 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <20080211164200.GB20791@topoi.pooq.com> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> Message-ID: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> My thoughts exactly. Let's not expend effort for no gain! On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote: > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: >> Do we know that this actually results in any real performance >> improvement. > > Not clear -- hardware is getting pretty clever at doing at run-time > the > things that compilers used to sweat blood doing at compile time. I > suspect that with fetch-and-branch-predictiong processors, the > difference may > unmeasurable. > > -- hendrik From wagner at elegosoft.com Mon Feb 11 18:19:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 18:19:59 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Quoting Tony Hosking : > Please -- no hierarchical namespaces. Ultimately, they need a > definitive hierarchy anyway. I wasn't going to write the code, so no need to worry. However, if this is not the solution we aim at, then we need to do something else about the increasing probability of the builder failing because some module in a completely different package which I don't even use directly happens to have the same name as my internal module and thus cannot be compiled. Or even worse: if I use two packages that happen to contain one module of the same name and have never been used together before. Olaf PS: This reminds me of Leslie Lamports definition of distributed computing: when a computer you didn't even know existed can render your own computer unusable :) > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> Quoting Jay : >> >>> It'd be nice if I could declare externals in modules. >>> In this example, setitimer_ only exists for the wrapper implementation. >>> I don't need it to be visible outside the one module that uses it. >>> I guess I could push it into an unexposed interface, even dedicate >>> "internal.i3" to it?Is that an ok idiom? >> >> Yes, use an internal interface of the package. But you should use >> another name (something longer and more unique), since the CM3 >> builder still has problems with multiple defined units AFAIK. >> >> This is something that should really be fixed, but that's another >> topic. (We'd need hierarchical name spaces, but introduce them in >> a compatible way.) >> >> Olaf >> >>> It's another problem that I don't know what to call these things.. >> >> This usually is _my_ problem :-) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Feb 11 18:52:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 12:52:33 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: This would be a bigger issue if we had dynamic loading like Java. To some degree, m3makefile imports give us some protection against name clashes. But, I do see your point that a name clash may prevent reuse of separately developed packages. On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Please -- no hierarchical namespaces. Ultimately, they need a >> definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf > > PS: This reminds me of Leslie Lamports definition of distributed > computing: when a computer you didn't even know existed > can render your own computer unusable :) > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >> >>> Quoting Jay : >>> >>>> It'd be nice if I could declare externals in modules. >>>> In this example, setitimer_ only exists for the wrapper >>>> implementation. >>>> I don't need it to be visible outside the one module that uses it. >>>> I guess I could push it into an unexposed interface, even >>>> dedicate "internal.i3" to it?Is that an ok idiom? >>> >>> Yes, use an internal interface of the package. But you should use >>> another name (something longer and more unique), since the CM3 >>> builder still has problems with multiple defined units AFAIK. >>> >>> This is something that should really be fixed, but that's another >>> topic. (We'd need hierarchical name spaces, but introduce them in >>> a compatible way.) >>> >>> Olaf >>> >>>> It's another problem that I don't know what to call these things.. >>> >>> This usually is _my_ problem :-) >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hendrik at topoi.pooq.com Mon Feb 11 21:06:13 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 15:06:13 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <20080211200613.GA20997@topoi.pooq.com> On Mon, Feb 11, 2008 at 06:19:59PM +0100, Olaf Wagner wrote: > Quoting Tony Hosking : > > >Please -- no hierarchical namespaces. Ultimately, they need a > >definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf Packages are a lot like modules on a larger scale. Maybe we should be able to syntactically nest modules? And enable modules to export some of their submodules? Or, if the source file gets unwieldy (it will!), use the nesting structure of directories as part of the syntax of the language? Or, for another approach: The various Eiffel implementations have separate module-interconnection language in which they get to collect modules into groups, and indicate some are internal to the group, and also things like <>, or <>. They set this up with programming-language syntax, syntactic nesting, indentation, and so forth. It seems to work, and you don't have to embed everything into an unweildy world-wide, global namespace. But the different implementations seem to have grown their own interconnection languages :-( -- hendrik From jayk123 at hotmail.com Mon Feb 11 22:42:30 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:42:30 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: Lack of hierarchical namespaces in Modula-3 has long bugged me, but I actually pretty much got over it. So agreed. :) Yes it sounds like the builder, not the language, has a bug. - Jay > Date: Mon, 11 Feb 2008 18:19:59 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] external in module?> > Quoting Tony Hosking :> > > Please -- no hierarchical namespaces. Ultimately, they need a> > definitive hierarchy anyway.> > I wasn't going to write the code, so no need to worry.> However, if this is not the solution we aim at, then we need to> do something else about the increasing probability of the builder> failing because some module in a completely different package> which I don't even use directly happens to have the same name> as my internal module and thus cannot be compiled. Or even worse:> if I use two packages that happen to contain one module of the> same name and have never been used together before.> > Olaf> > PS: This reminds me of Leslie Lamports definition of distributed> computing: when a computer you didn't even know existed> can render your own computer unusable :)> > > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote:> >> >> Quoting Jay :> >>> >>> It'd be nice if I could declare externals in modules.> >>> In this example, setitimer_ only exists for the wrapper implementation.> >>> I don't need it to be visible outside the one module that uses it.> >>> I guess I could push it into an unexposed interface, even dedicate > >>> "internal.i3" to it?Is that an ok idiom?> >>> >> Yes, use an internal interface of the package. But you should use> >> another name (something longer and more unique), since the CM3> >> builder still has problems with multiple defined units AFAIK.> >>> >> This is something that should really be fixed, but that's another> >> topic. (We'd need hierarchical name spaces, but introduce them in> >> a compatible way.)> >>> >> Olaf> >>> >>> It's another problem that I don't know what to call these things..> >>> >> This usually is _my_ problem :-)> >> -- > >> Olaf Wagner -- elego Software Solutions GmbH> >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:44:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:44:18 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:51:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:51:10 +0000 Subject: [M3devel] size_t? In-Reply-To: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: > These are OS-dependent! They should not be in BasicCtypes. 1) There is no Utypes on Windows. These are very basic types that belong at a very low level. In C++ for example, size_t is provided "automatically" by the compiler, no header is needed. 2) Are they really OS dependent? What OS makes my definitions wrong? On what 32 bit architecture is size_t not an unsigned 32 bit integer and ptrdiff_t not a signed 32 bit integer? Ditto for 64 bit. These should always be the same size as a pointer and with the proper signedness. Even if some of the *.i3 files make size_t = int, is that really correct? And, I assume int vs. long issue is not an issue here. Though they may be different types in C and C++, they need not be in Modula-3 (when they are the same size, of course) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 11:38:48 -0500> To: jayk123 at hotmail.com> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > INTEGER;> >> > really? it is signed?> > and we are sure this is going to be 64 bits on 64 bit targets?> >> > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > That has a 32 bit and 64 bit version, at least.> > These are OS-dependent! They should not be in BasicCtypes.> > >> >> > Does INTEGER effectively equal int or ptrdiff_t?> >> > - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:52:06 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:52:06 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: I guess I should switch the default calling convention and see what the code size difference is. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hendrik at topoi.pooq.comDate: Mon, 11 Feb 2008 21:44:18 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] __declspec(dllimport)? Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:56:55 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:56:55 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: If you want a precise scope in C++, just but in an opening brace. Just like how in Modula-3 (now I know) you can have "BEGIN" almost anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. It isn't often used though, granted. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] introducing VAR in more places?> Date: Mon, 11 Feb 2008 11:34:54 -0500> To: jayk123 at hotmail.com> > You can, except you need to explicitly give the block scope:> > VAR ...> BEGIN> ...> END;> > I find this much better than C++ where the scope of the new variable > is imprecisely defined.> > On Feb 11, 2008, at 4:29 AM, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and > > the compiler might do stack packing anyway, you can move all your > > locals up top like typical C, but still, how about for the module > > initializer?> > Still it seems good to me to do manual stack packing since it is > > often so easy..> > WITH helps, but only for "relative constants".> >> > It would be nice if the code below could have still loops until t0 ! > > = t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame..> >> > - Jay> >> >> >> > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > >> > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3> > >> > > Log message:> > > no need for globals here..> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 22:33:20 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 22:33:20 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <1202765600.8543.32.camel@faramir.m3w.org> But... We DO HAVE dynamic loading, and it's not altogether unlike Java :). Did these patches of mine made to CM3 HEAD? dd On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: > This would be a bigger issue if we had dynamic loading like Java. To > some degree, m3makefile imports give us some protection against name > clashes. But, I do see your point that a name clash may prevent > reuse of separately developed packages. > > On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > >> Please -- no hierarchical namespaces. Ultimately, they need a > >> definitive hierarchy anyway. > > > > I wasn't going to write the code, so no need to worry. > > However, if this is not the solution we aim at, then we need to > > do something else about the increasing probability of the builder > > failing because some module in a completely different package > > which I don't even use directly happens to have the same name > > as my internal module and thus cannot be compiled. Or even worse: > > if I use two packages that happen to contain one module of the > > same name and have never been used together before. > > > > Olaf > > > > PS: This reminds me of Leslie Lamports definition of distributed > > computing: when a computer you didn't even know existed > > can render your own computer unusable :) > > > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> > >>> Quoting Jay : > >>> > >>>> It'd be nice if I could declare externals in modules. > >>>> In this example, setitimer_ only exists for the wrapper > >>>> implementation. > >>>> I don't need it to be visible outside the one module that uses it. > >>>> I guess I could push it into an unexposed interface, even > >>>> dedicate "internal.i3" to it?Is that an ok idiom? > >>> > >>> Yes, use an internal interface of the package. But you should use > >>> another name (something longer and more unique), since the CM3 > >>> builder still has problems with multiple defined units AFAIK. > >>> > >>> This is something that should really be fixed, but that's another > >>> topic. (We'd need hierarchical name spaces, but introduce them in > >>> a compatible way.) > >>> > >>> Olaf > >>> > >>>> It's another problem that I don't know what to call these things.. > >>> > >>> This usually is _my_ problem :-) > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > >>> 23 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 23:03:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:03:22 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: That's also a good idea too. Though I think maybe safer to say: <*NT386:callingconvention push*><*NT386:callingconvention winapi*> ..bunch of decls .. <*NT386:callingconvention pop*> > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI. Tony, is /everything/ Win32 ugly? :) The status of SQLHWND is less clear to me now, seems I have trouble with the basic find-in-files.. Even so -- it used like once, its type is almost the same, the Windef definition is now available, the headers are almost the same. I did notice the Win32 headers actually #ifdef: #if defined(WIN32) || defined(OS2)typedef HWND SQLHWND;#elif defined (UNIX)typedef Widget SQLHWND;#else/* placehold for future O/S GUI window handle definition */typedef SQLPOINTER SQLHWND;#endif Might be nice to have a limited form of #if in Modula-3. I understand -- don't want to have to parse headers over and over. Maybe only if on TARGET and nothing else? Slippery slope. So far ODBC is the main place I've seen this and I'm just about over it. The status of OpenGL here isn't clear, seems maybe the opposite -- __stdcall on NT386, __cdecl on NT386GNU. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> Date: Mon, 11 Feb 2008 11:26:50 -0500> To: jayk123 at hotmail.com> > Why not simply default EXTERNAL on Win32 to WINAPI instead? That > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI.> > On Feb 11, 2008, at 5:13 AM, Jay wrote:> > > I know this won't be popular but...> >> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> >> > The differences are> >> > the UNUSED type SQLHWND is ADDRESS or HWND> > This should just be removed.> >> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> >> > For this and other reasons, I suggest that all CM3 frontends accept > > but silently> > ignore the Win32/x86 calling conventions in <*external*> pragmas,> > similar to what the non-x86 Windows compilers do.> >> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> >> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.> > It is a small safe change that will allow a little more Modula-3 > > source portability.> >> > A similar suggestion would be to change the default calling > > convention in Modula-3,> > it would very possibly reduce code size, but is very very very much > > a breaking> > change so probably can never happen.> > Better probably would be to a) add a switch for this b) extend > > the .m3exports> > or whatnot files to indicate what switch was used.> >> > A "blanket pragma" might also be good, so that the various *.i3 > > files can> > say just to assume __stdcall for the rest of the file instead of > > annotating each functions.> >> > - Jay> >> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:04:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:04:10 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Sorry. They belong in Cstddef.i3. size_t is already there. Let's try to stick to the C ".h" structure. size_t = INTEGER. On Feb 11, 2008, at 4:51 PM, Jay wrote: > > These are OS-dependent! They should not be in BasicCtypes. > > 1) There is no Utypes on Windows. > These are very basic types that belong at a very low level. > In C++ for example, size_t is provided "automatically" by the > compiler, no header is needed. > > 2) Are they really OS dependent? What OS makes my definitions wrong? > On what 32 bit architecture is size_t not an unsigned 32 bit > integer and ptrdiff_t not a signed 32 bit integer? > Ditto for 64 bit. > These should always be the same size as a pointer and with the > proper signedness. > Even if some of the *.i3 files make size_t = int, is that really > correct? > And, I assume int vs. long issue is not an issue here. > Though they may be different types in C and C++, they need not be > in Modula-3 (when they are the same size, of course) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > To: jayk123 at hotmail.com > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > > INTEGER; > > > > > > really? it is signed? > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > That has a 32 bit and 64 bit version, at least. > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 11 23:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:34:27 +0000 Subject: [M3devel] size_t? In-Reply-To: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: I did later notice size_t was there. I think what I earlier noticed was ptrdiff_t nowhere. > size_t = INTEGER. But unsigned presumably? What I had was correct, right? In C++ no header is needed for size_t, it is just so basic and widespread. Not sure about ptrdiff_t. Either way, they both do live in that middle ground between compiler and library -- a very low level -- as size_t is defined as the type of sizeof() expressions and ptrdiff_t is defined as the type you get when you subtract pointers. And you don't need nay header to use sizeof() or subtract pointers. If it were really up to me, I'd have the Modula-3 language predefine all of int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. There is a corralary dilemna here that I haven't figured out, and have seen code address that I haven't adjusted to yet. That is, the code uses uint32 "everywhere", instead of something "more abstract/vague". When it comes down to it, I suspect this is the right thing. The abstraction only seems to buy problems. UNLESS you have a processor with a larger natural integer that performs poorly on smaller integers, or a processor that perfs badly with 32 bit integers. Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. In many and growing systems, "int", besides its signedness, is too small for many occurences. That is the problem I think in C. If Modula-3 has essentially defined INTEGER to be the size of a pointer, then ok. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 17:04:10 -0500> To: jayk123 at hotmail.com> > Sorry.> > They belong in Cstddef.i3. size_t is already there. Let's try to > stick to the C ".h" structure.> > size_t = INTEGER.> > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > > > These are OS-dependent! They should not be in BasicCtypes.> >> > 1) There is no Utypes on Windows.> > These are very basic types that belong at a very low level.> > In C++ for example, size_t is provided "automatically" by the > > compiler, no header is needed.> >> > 2) Are they really OS dependent? What OS makes my definitions wrong?> > On what 32 bit architecture is size_t not an unsigned 32 bit > > integer and ptrdiff_t not a signed 32 bit integer?> > Ditto for 64 bit.> > These should always be the same size as a pointer and with the > > proper signedness.> > Even if some of the *.i3 files make size_t = int, is that really > > correct?> > And, I assume int vs. long issue is not an issue here.> > Though they may be different types in C and C++, they need not be > > in Modula-3 (when they are the same size, of course)> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > To: jayk123 at hotmail.com> > >> > >> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > >> > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t => > > > INTEGER;> > > >> > > > really? it is signed?> > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > >> > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > That has a 32 bit and 64 bit version, at least.> > >> > > These are OS-dependent! They should not be in BasicCtypes.> > >> > > >> > > >> > > > Does INTEGER effectively equal int or ptrdiff_t?> > > >> > > > - Jay> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:40:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:40:44 -0500 Subject: [M3devel] external in module? In-Reply-To: <1202765600.8543.32.camel@faramir.m3w.org> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> <1202765600.8543.32.camel@faramir.m3w.org> Message-ID: Not sure... On Feb 11, 2008, at 4:33 PM, Dragi?a Duri? wrote: > But... We DO HAVE dynamic loading, and it's not altogether unlike > Java :). > > Did these patches of mine made to CM3 HEAD? > > dd > > On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: >> This would be a bigger issue if we had dynamic loading like Java. To >> some degree, m3makefile imports give us some protection against name >> clashes. But, I do see your point that a name clash may prevent >> reuse of separately developed packages. >> >> On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> Please -- no hierarchical namespaces. Ultimately, they need a >>>> definitive hierarchy anyway. >>> >>> I wasn't going to write the code, so no need to worry. >>> However, if this is not the solution we aim at, then we need to >>> do something else about the increasing probability of the builder >>> failing because some module in a completely different package >>> which I don't even use directly happens to have the same name >>> as my internal module and thus cannot be compiled. Or even worse: >>> if I use two packages that happen to contain one module of the >>> same name and have never been used together before. >>> >>> Olaf >>> >>> PS: This reminds me of Leslie Lamports definition of distributed >>> computing: when a computer you didn't even know existed >>> can render your own computer unusable :) >>> >>>> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >>>> >>>>> Quoting Jay : >>>>> >>>>>> It'd be nice if I could declare externals in modules. >>>>>> In this example, setitimer_ only exists for the wrapper >>>>>> implementation. >>>>>> I don't need it to be visible outside the one module that uses >>>>>> it. >>>>>> I guess I could push it into an unexposed interface, even >>>>>> dedicate "internal.i3" to it?Is that an ok idiom? >>>>> >>>>> Yes, use an internal interface of the package. But you should use >>>>> another name (something longer and more unique), since the CM3 >>>>> builder still has problems with multiple defined units AFAIK. >>>>> >>>>> This is something that should really be fixed, but that's another >>>>> topic. (We'd need hierarchical name spaces, but introduce them in >>>>> a compatible way.) >>>>> >>>>> Olaf >>>>> >>>>>> It's another problem that I don't know what to call these >>>>>> things.. >>>>> >>>>> This usually is _my_ problem :-) >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>> 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>> Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Feb 12 00:37:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 18:37:56 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. Subtracting two pointers yields ptrdiff_t, so in M3 it would presumably be INTEGER. size_t is what sizeof returns, so I imagine size_t=CARDINAL is probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should better be Word.T to match C's unsigned interpretation. Of course, Word.T is simply INTEGER anyway in the current CM3 implementation. Note that neither of these need to be defined in the 32bit/64bit subdirectories since they are straightforwardly the same as the underlying word size. On Feb 11, 2008, at 5:34 PM, Jay wrote: > I did later notice size_t was there. > I think what I earlier noticed was ptrdiff_t nowhere. > > > size_t = INTEGER. > > But unsigned presumably? > > What I had was correct, right? > In C++ no header is needed for size_t, it is just so basic and > widespread. > Not sure about ptrdiff_t. > > Either way, they both do live in that middle ground between > compiler and library -- a very low level -- > as size_t is defined as the type of sizeof() expressions and > ptrdiff_t is defined as the type you get when you subtract > pointers. And you don't need nay header to use sizeof() or subtract > pointers. > > If it were really up to me, I'd have the Modula-3 language > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > There is a corralary dilemna here that I haven't figured out, and > have seen code address that I haven't adjusted to yet. That is, the > code uses uint32 "everywhere", instead of something "more abstract/ > vague". When it comes down to it, I suspect this is the right > thing. The abstraction only seems to buy problems. UNLESS you have > a processor with a larger natural integer that performs poorly on > smaller integers, or a processor that perfs badly with 32 bit > integers. > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > In many and growing systems, "int", besides its signedness, is too > small for many occurences. > That is the problem I think in C. If Modula-3 has essentially > defined INTEGER to be the size of a pointer, then ok. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > To: jayk123 at hotmail.com > > > > Sorry. > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > stick to the C ".h" structure. > > > > size_t = INTEGER. > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > 1) There is no Utypes on Windows. > > > These are very basic types that belong at a very low level. > > > In C++ for example, size_t is provided "automatically" by the > > > compiler, no header is needed. > > > > > > 2) Are they really OS dependent? What OS makes my definitions > wrong? > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > integer and ptrdiff_t not a signed 32 bit integer? > > > Ditto for 64 bit. > > > These should always be the same size as a pointer and with the > > > proper signedness. > > > Even if some of the *.i3 files make size_t = int, is that really > > > correct? > > > And, I assume int vs. long issue is not an issue here. > > > Though they may be different types in C and C++, they need not be > > > in Modula-3 (when they are the same size, of course) > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > size_t = > > > > > INTEGER; > > > > > > > > > > really? it is signed? > > > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > - Jay > > > > > > Need to know the score, the latest news, or you need your > Hotmail?- > > > get your "fix". Check it out. > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Tue Feb 12 02:05:39 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:05:39 +0000 Subject: [M3devel] size_t? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: I think ANSI C is a bit of a mess here. For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... Anyway.. But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. For example, strlen returns size_t, so #include must define it (directly or indirectly). Malloc takes size_t, so #include must define it (directly or indirectly). fread/fwrite/stdio.h ditto. I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). Pushing some things into fewer larger integers is a step in this direction. It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. So maybe just size_t is missing? I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? Good enough? Really, I'm sure you have all figured out, I want Modula-3 to look more like C. :) The more I use C lately (as opposed to C++) and the more I use Modula-3 lately..the more I find C perfectly ok, the unsafety easy enough to not be bitten by, the more the heap allocations and copying that "safety" cost seem not worth it.. It's an interesting system largely just because it is yet another system, in need (arguably) of more targets, and where "NT386" exists but gets little support. Someone who "likes" Modula-3 more would serve it better than me, perhaps. But I'm here. :) I also like that a decent module system was worked out such as to build fast, at least when using the integrated backend. So maybe I just write all my Modula-3 as "unsafe" and be happy. :) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 18:37:56 -0500> To: jayk123 at hotmail.com> > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h.> > Subtracting two pointers yields ptrdiff_t, so in M3 it would > presumably be INTEGER.> size_t is what sizeof returns, so I imagine size_t=CARDINAL is > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > better be Word.T to match C's unsigned interpretation. Of course, > Word.T is simply INTEGER anyway in the current CM3 implementation. > Note that neither of these need to be defined in the 32bit/64bit > subdirectories since they are straightforwardly the same as the > underlying word size.> > On Feb 11, 2008, at 5:34 PM, Jay wrote:> > > I did later notice size_t was there.> > I think what I earlier noticed was ptrdiff_t nowhere.> >> > > size_t = INTEGER.> >> > But unsigned presumably?> >> > What I had was correct, right?> > In C++ no header is needed for size_t, it is just so basic and > > widespread.> > Not sure about ptrdiff_t.> >> > Either way, they both do live in that middle ground between > > compiler and library -- a very low level --> > as size_t is defined as the type of sizeof() expressions and > > ptrdiff_t is defined as the type you get when you subtract > > pointers. And you don't need nay header to use sizeof() or subtract > > pointers.> >> > If it were really up to me, I'd have the Modula-3 language > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER.> > There is a corralary dilemna here that I haven't figured out, and > > have seen code address that I haven't adjusted to yet. That is, the > > code uses uint32 "everywhere", instead of something "more abstract/ > > vague". When it comes down to it, I suspect this is the right > > thing. The abstraction only seems to buy problems. UNLESS you have > > a processor with a larger natural integer that performs poorly on > > smaller integers, or a processor that perfs badly with 32 bit > > integers.> >> > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t.> > In many and growing systems, "int", besides its signedness, is too > > small for many occurences.> > That is the problem I think in C. If Modula-3 has essentially > > defined INTEGER to be the size of a pointer, then ok.> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 17:04:10 -0500> > > To: jayk123 at hotmail.com> > >> > > Sorry.> > >> > > They belong in Cstddef.i3. size_t is already there. Let's try to> > > stick to the C ".h" structure.> > >> > > size_t = INTEGER.> > >> > > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > >> > > > 1) There is no Utypes on Windows.> > > > These are very basic types that belong at a very low level.> > > > In C++ for example, size_t is provided "automatically" by the> > > > compiler, no header is needed.> > > >> > > > 2) Are they really OS dependent? What OS makes my definitions > > wrong?> > > > On what 32 bit architecture is size_t not an unsigned 32 bit> > > > integer and ptrdiff_t not a signed 32 bit integer?> > > > Ditto for 64 bit.> > > > These should always be the same size as a pointer and with the> > > > proper signedness.> > > > Even if some of the *.i3 files make size_t = int, is that really> > > > correct?> > > > And, I assume int vs. long issue is not an issue here.> > > > Though they may be different types in C and C++, they need not be> > > > in Modula-3 (when they are the same size, of course)> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] size_t?> > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > >> > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > > >> > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > size_t => > > > > > INTEGER;> > > > > >> > > > > > really? it is signed?> > > > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > > > >> > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > > > That has a 32 bit and 64 bit version, at least.> > > > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > > >> > > > > >> > > > > >> > > > > > Does INTEGER effectively equal int or ptrdiff_t?> > > > > >> > > > > > - Jay> > > >> > > > Need to know the score, the latest news, or you need your > > Hotmail?-> > > > get your "fix". Check it out.> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 02:21:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:21:24 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86. __clrcall sort of doesn't count. It really must means "managed code", using the only calling convention available. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Feb 12 02:29:12 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:29:12 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47AF72B5.2080308@wichita.edu> References: <47AF72B5.2080308@wichita.edu> Message-ID: The liberalised alignment rules are required for the native Mac OS X API and should stay. You cannot use that API without them. I think the pragma is not required and can be removed. I agree with all the points you make. The effect of the modified alignment rules it to allow *packed* structures to have members aligned on byte boundaries. This has the effect of packing the fields in the tightest arrangement allowed by the platform. This might affect performance, but if the user is concerned about this they should specify field bit sizes that deliver improved performance. I don't see a need to specify this on a structure level, for the reasons you give and because the difference isn't significant enough in the case of packed structures and their physical layout and restrictions are platform dependent anyway. I might also add that the alignment code is currently broken on I386_DARWIN. - Darko On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > Does anybody know about the status of pragma <*LAZYALIGN*>? Is it > being used anywhere? > > It is not documented in pragmas.html. The compiler front end appears > to accept it. (In fact, Decls.m3 contains constants that suggest > limitations on what declarations the pragma can appear on, but these > are not actually enforced.) It liberalizes the alignment rules, > generally allowing scalars to start on any byte boundary. > > Pickles have to be able to reconstruct the layout of types as the > compiler would have done it for a machine (on which a now-being-read > pickle was written) with different word size and alignment properties. > Currently, pickles are completely unaware of lazy alignment. It > would have to be encoded in type descriptions generated by the > compiler > using TipeDesc and read by pickles using RTTipe. > > Most troubling to me is what looks like a linguistic Pandora's box. > The pragma can be associated with any constant, variable, or type > _declaration_ (not type definition), with the result that different > values of the same type can actually be different in their alignment > rules and thus their layout. Similarly for different identifiers > equated to the same type. Although the effects of this could possibly > be hidden from the programmer in purely safe code, not so with unsafe > code. I haven't thoroughly thought this through, but seems to me to > really fly in the face of the whole typing philosophy of the language. > > For example, if pickles were to read in an object value, and there > were >1 variants of the object's type in the reading program, > differing > only in the alignment rules, how would it decide which one to build? > In fact, ignoring pickles altogether and just looking at a single > program, > if the object's type doesn't actually uniquely give its memory layout, > how can it be accessed correctly? > > Additionally, a quick look at the compiler suggests it won't generate > correct code for whole record assignment when the LHS and RHS are the > same type but have different alignment characteristics. > > The more I think about it, it seems the only workable possibilities > are: > > 1) Require the pragma to be associated only with a type _definition_ > not a > declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > this a > property of the type that propagates to all names for the type and > all variables, constants, etc. Also, this would make this property > a part of the type signature that pickles uses when reading, -OR- > > 2) Forget it altogether. > > What do people think? > -- > ------------------------------------------------------------- > 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 darko at darko.org Tue Feb 12 02:37:49 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:37:49 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> I think it's not a good idea. I think all platform specific code should be in a separate file. I'd also like to see an option to move calling conventions to the makefile rather than in pramas to avoid having to duplicate interface files just to have a different calling convention for a different platform. - Darko On 12/02/2008, at 12:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew > more lower level details and playing games with calling conventions > was something anyone could do. Most other current systems are rooted > in C programming. Working in C, calling conventions are generally in > a hidden layer below what anyone thinks about. Therefore, the > smaller number of capable people working at that level have the good > sense to only have one calling convention. No more systems will > evolve from "small", at least not without having observed this > history. Therefore, there will no longer be multiple calling > conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:07:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:07:04 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So, here's the thing about pragmas. According to the language definition, they can be ignored and the program should still "mean" the same thing. Preprocessing definitely does not fit that model. On Feb 11, 2008, at 8:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc > directory and bringing up ignoring WINAPI on non-NT386 or prefixing > calling conventions with a target. > > This reminds me of an important point here however -- nobody else > is going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from > "small" systems, where assembly programming was common, more people > knew more lower level details and playing games with calling > conventions was something anyone could do. Most other current > systems are rooted in C programming. Working in C, calling > conventions are generally in a hidden layer below what anyone > thinks about. Therefore, the smaller number of capable people > working at that level have the good sense to only have one calling > convention. No more systems will evolve from "small", at least not > without having observed this history. Therefore, there will no > longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:08:27 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:27 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <65396937-761B-4CA3-A20F-A04D53FAA6D2@cs.purdue.edu> C and Modula-3 fill different needs. I use C when it makes sense. I use Modula-3 when it makes sense. I'd hate to blur the distinction between them though! On Feb 11, 2008, at 8:05 PM, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. > That is good. Each header exposes certain names and few names are > exposed by more than one header. As well, for good measure, your > own #includes of ANSI C headers I believe is speced as order- > independent. These are all aspects of a "good module system", > except this solid foundation is built on a foundation of quicksand > and there is inadequate support for it in the language -- i.e. no > static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from > multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must > define it (directly or indirectly). > Malloc takes size_t, so #include must define it > (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing > all of stddef.h however. > IF NOT, then there must be some underlying implementation defined > layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is > probably usually a bad idea, but it can also be darn convenient. > Just #include everything, and have everything available in the > global namespace. > The "language" does live in this space. INTEGER is ALWAYS available > and always has the same meaning (per-target). I cannot redefine it > (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this > direction. > It breaks "modularity" and so should be done very selectively, but / > arguably/ size_t and ptrdiff_t are fundamental enough to warrant > such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be > in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on > all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? > > Really, I'm sure you have all figured out, I want Modula-3 to look > more like C. :) > The more I use C lately (as opposed to C++) and the more I use > Modula-3 lately..the more I find C perfectly ok, the unsafety easy > enough to not be bitten by, the more the heap allocations and > copying that "safety" cost seem not worth it.. > > It's an interesting system largely just because it is yet another > system, in need (arguably) of more targets, and where "NT386" > exists but gets little support. Someone who "likes" Modula-3 more > would serve it better than me, perhaps. But I'm here. :) > > I also like that a decent module system was worked out such as to > build fast, at least when using the integrated backend. > So maybe I just write all my Modula-3 as "unsafe" and be happy. :) > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 18:37:56 -0500 > > To: jayk123 at hotmail.com > > > > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. > > > > Subtracting two pointers yields ptrdiff_t, so in M3 it would > > presumably be INTEGER. > > size_t is what sizeof returns, so I imagine size_t=CARDINAL is > > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > > better be Word.T to match C's unsigned interpretation. Of course, > > Word.T is simply INTEGER anyway in the current CM3 implementation. > > Note that neither of these need to be defined in the 32bit/64bit > > subdirectories since they are straightforwardly the same as the > > underlying word size. > > > > On Feb 11, 2008, at 5:34 PM, Jay wrote: > > > > > I did later notice size_t was there. > > > I think what I earlier noticed was ptrdiff_t nowhere. > > > > > > > size_t = INTEGER. > > > > > > But unsigned presumably? > > > > > > What I had was correct, right? > > > In C++ no header is needed for size_t, it is just so basic and > > > widespread. > > > Not sure about ptrdiff_t. > > > > > > Either way, they both do live in that middle ground between > > > compiler and library -- a very low level -- > > > as size_t is defined as the type of sizeof() expressions and > > > ptrdiff_t is defined as the type you get when you subtract > > > pointers. And you don't need nay header to use sizeof() or > subtract > > > pointers. > > > > > > If it were really up to me, I'd have the Modula-3 language > > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > > > There is a corralary dilemna here that I haven't figured out, and > > > have seen code address that I haven't adjusted to yet. That is, > the > > > code uses uint32 "everywhere", instead of something "more > abstract/ > > > vague". When it comes down to it, I suspect this is the right > > > thing. The abstraction only seems to buy problems. UNLESS you have > > > a processor with a larger natural integer that performs poorly on > > > smaller integers, or a processor that perfs badly with 32 bit > > > integers. > > > > > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > > > In many and growing systems, "int", besides its signedness, is too > > > small for many occurences. > > > That is the problem I think in C. If Modula-3 has essentially > > > defined INTEGER to be the size of a pointer, then ok. > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Sorry. > > > > > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > > > stick to the C ".h" structure. > > > > > > > > size_t = INTEGER. > > > > > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > 1) There is no Utypes on Windows. > > > > > These are very basic types that belong at a very low level. > > > > > In C++ for example, size_t is provided "automatically" by the > > > > > compiler, no header is needed. > > > > > > > > > > 2) Are they really OS dependent? What OS makes my definitions > > > wrong? > > > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > > > integer and ptrdiff_t not a signed 32 bit integer? > > > > > Ditto for 64 bit. > > > > > These should always be the same size as a pointer and with the > > > > > proper signedness. > > > > > Even if some of the *.i3 files make size_t = int, is that > really > > > > > correct? > > > > > And, I assume int vs. long issue is not an issue here. > > > > > Though they may be different types in C and C++, they need > not be > > > > > in Modula-3 (when they are the same size, of course) > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: [M3devel] size_t? > > > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > > size_t = > > > > > > > INTEGER; > > > > > > > > > > > > > > really? it is signed? > > > > > > > and we are sure this is going to be 64 bits on 64 bit > targets? > > > > > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > > > > > - Jay > > > > > > > > > > Need to know the score, the latest news, or you need your > > > Hotmail?- > > > > > get your "fix". Check it out. > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Tue Feb 12 03:08:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:46 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> Message-ID: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Indeed! On Feb 11, 2008, at 8:37 PM, Darko wrote: > I think it's not a good idea. I think all platform specific code > should be in a separate file. I'd also like to see an option to > move calling conventions to the makefile rather than in pramas to > avoid having to duplicate interface files just to have a different > calling convention for a different platform. > > - Darko > > > On 12/02/2008, at 12:21 PM, Jay wrote: > >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, >> or an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in >> an interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, >> just sending out the bait... >> >> Obviously this was triggered by my happening into the odbc >> directory and bringing up ignoring WINAPI on non-NT386 or >> prefixing calling conventions with a target. >> >> This reminds me of an important point here however -- nobody else >> is going to make the mistake of ever having multiple calling >> conventions. Therefore the generality of prefixing WINAPI with >> NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from >> "small" systems, where assembly programming was common, more >> people knew more lower level details and playing games with >> calling conventions was something anyone could do. Most other >> current systems are rooted in C programming. Working in C, calling >> conventions are generally in a hidden layer below what anyone >> thinks about. Therefore, the smaller number of capable people >> working at that level have the good sense to only have one calling >> convention. No more systems will evolve from "small", at least not >> without having observed this history. Therefore, there will no >> longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 From rodney.bates at wichita.edu Tue Feb 12 05:17:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 11 Feb 2008 22:17:13 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: <47B11DC9.1040902@wichita.edu> I don't think this is what Tony meant. In C++, an opening brace starts a block, but every local declaration in that block has its own unique scope that only starts at that declaration and goes to the end of the block. This is particularly messy because the local declarations of a block need not all precede all the statements, and even worse because the distinction between declarations and statements is extremely subtle and, unless things have changed, never actually defined. (Do you remember Stroustrup's famous quote when taken to task about this? "If it looks like a declaration, it's a declaration. If it looks like a statement, it's a statement. If it doesn't look like either, it's a syntax error.") In contrast, in Modula-3, the scope of every local declaration starts at the beginning of the block and ends at the end of the block. The C++ reference makes an attempt at defining different terms for the entire block and the region where the identifier can be referred-to, i.e., from declaration to end of block (which I have called "scope" here). But as I recall, they ended up carefully defining their terminology in one section but then not using it consistently in the rest of the language definition. One of the few things Ada did better than Modula-3 was that the syntax has an explicit delimiter at all three relevant points: beginning of block, between declarations and statements, and end of block. (But it still has C++-like scopes for every declaration>.) I am an adamant believer in a high level of syntactic explicitness. Ada Modula-3 C++ start of block: DECLARE { between decls and stmts: BEGIN BEGIN end of block: END END } Jay wrote: > If you want a precise scope in C++, just but in an opening brace. > Just like how in Modula-3 (now I know) you can have "BEGIN" almost > anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. > It isn't often used though, granted. > > - Jay > > ------------------------------------------------------------------------ > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] introducing VAR in more places? > > Date: Mon, 11 Feb 2008 11:34:54 -0500 > > To: jayk123 at hotmail.com > > > > You can, except you need to explicitly give the block scope: > > > > VAR ... > > BEGIN > > ... > > END; > > > > I find this much better than C++ where the scope of the new variable > > is imprecisely defined. > > > > On Feb 11, 2008, at 4:29 AM, Jay wrote: > > > > > Does anyone else find it bothersome that you can't introduce VARs > > > anywhere? Kind of like in C++? > > > Ok, or if you grant that frame size doesn't matter THAT much, and > > > the compiler might do stack packing anyway, you can move all your > > > locals up top like typical C, but still, how about for the module > > > initializer? > > > Still it seems good to me to do manual stack packing since it is > > > often so easy.. > > > WITH helps, but only for "relative constants". > > > > > > It would be nice if the code below could have still loops until t0 ! > > > = t1, but the repeat condition is outside the scope in which t1 is > > > available. This feels quite lame.. > > > > > > - Jay > > > > > > > > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > > To: m3commit at elegosoft.com > > > > From: jkrell at elego.de > > > > Subject: [M3commit] CVS Update: cm3 > > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > > > Modified files: > > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message: > > > > no need for globals here.. > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > ------------------------------------------------------------------------ > Connect and share in new ways with Windows Live. Get it now! > -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Tue Feb 12 05:10:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:10:20 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <427855DD-C178-414E-8AEC-3BB723699B87@cs.purdue.edu> Score a big win for the regression test framework! I would not have devoted the time to finding the recently fixed race condition for mutex/condition initialization in the pthreads-based thread implementation if I had not been told about the problem with p007 on FreeBSD4. The problem only revealed itself in a repeatable way on FreeBSD4, and not repeatably enough to be debuggable on all the other systems I use (I386_DARWIN, PPC_DARWIN, LINUXLIBC6, or Solaris -- except for a clue in an error report from Alex Bochanek). Regression testing on multiple platforms is practically the only way to shake out these sorts of insidious bugs. Yay! Good work guys! On Jan 31, 2008, at 6:43 AM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression >> testing >> would help and should be introduced. Tests should be run daily/ >> nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these >> services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for > others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be > transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a > FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of > course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to > participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh > cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment > this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox /usr/ > local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue Feb 12 05:27:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:27:35 -0500 Subject: [M3devel] scripts/PKGS Message-ID: I notice scripts/PKGS is no longer in the repository. Does this get generated somehow now? I know that do-cm3-std.sh depends on it because my copy of PKGS was broken (missing sysutils). Can someone explain to me how the build scripts have changed and how I should be using them? From darko at darko.org Tue Feb 12 05:37:52 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 15:37:52 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B1168F.8020302@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> Message-ID: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for historical reasons. All other structures should use normal alignment to be compatible with C and Unix interfaces. The alignment change was implemented to be supported only in packed structures as a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly restrictive alignment rules in packed structures. On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > It sounds like all that Mac OS X needs is for _all_ types in an entire > program to use the liberal packing rules. Have I understood > correctly? > I would have no grief over that. > > Darko wrote: >> The liberalised alignment rules are required for the native Mac OS >> X API and should stay. You cannot use that API without them. I >> think the pragma is not required and can be removed. I agree with >> all the points you make. The effect of the modified alignment >> rules it to allow *packed* structures to have members aligned on >> byte boundaries. This has the effect of packing the fields in the >> tightest arrangement allowed by the platform. This might affect >> performance, but if the user is concerned about this they should >> specify field bit sizes that deliver improved performance. I don't >> see a need to specify this on a structure level, for the reasons >> you give and because the difference isn't significant enough in >> the case of packed structures and their physical layout and >> restrictions are platform dependent anyway. >> I might also add that the alignment code is currently broken on >> I386_DARWIN. >> - Darko >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>> being used anywhere? >>> >>> It is not documented in pragmas.html. The compiler front end >>> appears >>> to accept it. (In fact, Decls.m3 contains constants that suggest >>> limitations on what declarations the pragma can appear on, but these >>> are not actually enforced.) It liberalizes the alignment rules, >>> generally allowing scalars to start on any byte boundary. >>> >>> Pickles have to be able to reconstruct the layout of types as the >>> compiler would have done it for a machine (on which a now-being-read >>> pickle was written) with different word size and alignment >>> properties. >>> Currently, pickles are completely unaware of lazy alignment. It >>> would have to be encoded in type descriptions generated by the >>> compiler >>> using TipeDesc and read by pickles using RTTipe. >>> >>> Most troubling to me is what looks like a linguistic Pandora's box. >>> The pragma can be associated with any constant, variable, or type >>> _declaration_ (not type definition), with the result that different >>> values of the same type can actually be different in their alignment >>> rules and thus their layout. Similarly for different identifiers >>> equated to the same type. Although the effects of this could >>> possibly >>> be hidden from the programmer in purely safe code, not so with >>> unsafe >>> code. I haven't thoroughly thought this through, but seems to me >>> to >>> really fly in the face of the whole typing philosophy of the >>> language. >>> >>> For example, if pickles were to read in an object value, and there >>> were >1 variants of the object's type in the reading program, >>> differing >>> only in the alignment rules, how would it decide which one to build? >>> In fact, ignoring pickles altogether and just looking at a single >>> program, >>> if the object's type doesn't actually uniquely give its memory >>> layout, >>> how can it be accessed correctly? >>> >>> Additionally, a quick look at the compiler suggests it won't >>> generate >>> correct code for whole record assignment when the LHS and RHS are >>> the >>> same type but have different alignment characteristics. >>> >>> The more I think about it, it seems the only workable >>> possibilities are: >>> >>> 1) Require the pragma to be associated only with a type >>> _definition_ not a >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>> this a >>> property of the type that propagates to all names for the type and >>> all variables, constants, etc. Also, this would make this property >>> a part of the type signature that pickles uses when reading, -OR- >>> >>> 2) Forget it altogether. >>> >>> What do people think? >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 hendrik at topoi.pooq.com Tue Feb 12 05:35:55 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:35:55 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <20080212043555.GA21429@topoi.pooq.com> On Tue, Feb 12, 2008 at 01:05:39AM +0000, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must define it (directly or indirectly). > Malloc takes size_t, so #include must define it (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. > IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. > The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this direction. > It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? The real requirement on size_t is that values of that type can be used freely in address arithmetic. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:38:21 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:38:21 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080212043821.GB21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:03:22PM +0000, Jay wrote: > Tony, is /everything/ Win32 ugly? :) No. Some of the video games are breathtakingly beautiful. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:39:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:39:29 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: <20080212043929.GC21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 09:52:06PM +0000, Jay wrote: > I guess I should switch the default calling convention and see what > the code size difference is. > Yes. Code size can be neasured. -- hendrik From jayk123 at hotmail.com Tue Feb 12 07:16:45 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:16:45 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: It is generated if it doesn't exist. Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them?> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:18:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:18:01 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: <20080212042047.A12E210D4686@birch.elegosoft.com> References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I added some files a while ago and someone either complained or added them, so I've been adding them since. - Jay > Date: Tue, 12 Feb 2008 05:20:47 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:20:47> > Modified files:> cm3/m3-sys/cm3/src/: m3makefile > > Log message:> Let's avoid RCS id stuff shall we. Just clutters up the files...> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:22:28 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:22:28 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available. There is/was a compilation problem with what I was doing. I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 08:20:33 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 07:20:33 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: This is not my doing, at least not knowingly, just reporting the facts, officer. I wonder if maybe something more like Randy's scheme should be put in place. He has a smaller hand authored checked in file. The current system is more automatic, but doesn't handle changes automatically, and generates far more data than necessary I think. Perhaps another approach is to keep a timestamp/revision, embedded in the name, pkgs.v1234, someone rev the name as needed, and if the desired name doesn't exist rm pkgs.v* and recreate? This is a nice simple model imho. Changes are also very infrequent in my short observance. (I do go so far in the python directory to always use forward slashes, so the files are more portable across systems. :) Really, you know, it doesn't matter what the underlying system uses, as long as you translate at all the appropriate places and as long as you pick a syntax that can represent everything needed (not necessarily anything the underlying system supports). However you do have to translate at all the appropriate levels, possibly under the guidance of user settings. In particular, I can set M3CONFIG, M3ROOT, etc. to have forward slashes and it works just fine on Windows, but when errors are reported with paths, I can't paste them into file.open dialogs without changing the slashes....) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 06:16:45 +0000Subject: Re: [M3devel] scripts/PKGS It is generated if it doesn't exist.Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them? _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 09:16:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 09:16:42 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken Message-ID: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Tonight some of the tinderbox builds failed for CM3. First I thought it was just these changes to FilePosix which had already been fixed: ---------------------------- revision 1.8 date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: +1 -1; commitid: pvCLLyqdDKQm24Rs; This checkin fixes something Jay left behind. Please check things build on platforms other than yours before making changes. The VAL is necessary on some targets because 0 is INTEGER whereas result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly compared with an INTEGER (result). The VAL is how we do the conversion to LONGINT. On platforms where Utypes.off_t is INTEGER this code will work the same as it is. ---------------------------- revision 1.7 date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: +1 -1; commitid: j3ewJLumr87rqWQs; more cygwin header cleanup, various dead types were used in further dead types in Ushm.i3; go ahead and delete dead stuff instead of commenting out remove seemingly unnecessary VAL() that fails to compile but when I try to build now on my FreeBSD system, I get this from cm3: % ./m3-sys/cm3/FreeBSD4/cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 *** ^C Please check all the latest commits carefully and back out anything that seems suspicious or has not been tested. Thanks, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Feb 12 09:27:40 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:27:40 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: drat...I'd like to punt just a few hours here and will get to it then. Sorry. I hardly changed anything "live" other than what Tony put back. Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 09:45:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:45:24 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: The only other non-NT386/GNU change by me, from a quick scan of ChangeLog, is: 2008-02-10 23:24 jkrell * m3-libs/m3core/src/: runtime/m3makefile, thread/m3makefile, thread/Common/SchedulerPosix.i3, thread/Common/m3makefile, thread/POSIX/SchedulerPosix.i3, thread/POSIX/m3makefile, thread/PTHREAD/SchedulerPosix.i3, thread/PTHREAD/m3makefile, thread/WIN32/ThreadWin32.m3: cheat just a tad and provide SchedulePosix interface on Win32 albeit not a good implementation currently this way NT386GNU can build with Win32 threads and cm3 gets as far as printing an error and exiting, probably something to do with pesky slashes; a lot better than hanging due to nanosleep failing and worrying about a lot of non trivial cygwin code.. which looks very ok. I moved SchedulerPosix to common and provided a do-nothing implementation for NT386. This is so NT386GNU can use native Win32 threads, but Posix in other places like i/o. (Sometimes I wonder...maybe all that's needed is handling forward and backward slashes the same c:/foo/bar, which I already put in, plus allowing X Windows... (Trestle builds now btw...std packages get at least as far as anim3d. Running stuff is known to have problems..the slash issues were just because I had backslashes (and colons) in paths in environment variables... the current problem is that cm3 always seems to think files are out of date and that all builds fail, but it does actually run cm3cg over everything and seems to work...surely an easy issue to deal with...oh I think m3bundle crashes, the only other thing I've run besides cm3...like..for example, keeping time in seconds since 1970 in a 32bit signed integer seems more like a bug than a feature....maybe I'll start another thread here....even the Win32 Modula-3 interfaces I think use that poor representation, just that they go to the effort of converting from a better format....)) Anyway I'll at least test on birch later and maybe install FreeBSD in a virtual machine..... - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 08:27:40 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken drat...I'd like to punt just a few hours here and will get to it then.Sorry.I hardly changed anything "live" other than what Tony put back.Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 11:34:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 11:34:42 +0100 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Quoting Tony Hosking : > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it because > my copy of PKGS was broken (missing sysutils). Can someone explain to > me how the build scripts have changed and how I should be using them? PKGS has never been checked-in and should not as far as I know. It contains workspace-dependent paths and is built by find-packages.sh if I remember correctly. All shell scripts will generate it if it does not exist. It can be deleted any time, and indeed must be deleted if packages are added (or they will not be found). This is arguably a bug, but then all the scripts were never intended to be a general user interface for CM3 users (only for the maintenance). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Feb 12 12:23:21 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:23:21 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: Obviously if the paths are relative to CM3_ROOT, it isn't workspace dependent... How about my idea of making the name have a "version" in it, and the version can be bumped as needed? Or making it contain relative paths and just maintain it manually? - Jay > Date: Tue, 12 Feb 2008 11:34:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] scripts/PKGS> > Quoting Tony Hosking :> > > I notice scripts/PKGS is no longer in the repository. Does this get> > generated somehow now? I know that do-cm3-std.sh depends on it because> > my copy of PKGS was broken (missing sysutils). Can someone explain to> > me how the build scripts have changed and how I should be using them?> > PKGS has never been checked-in and should not as far as I know.> It contains workspace-dependent paths and is built by find-packages.sh> if I remember correctly. All shell scripts will generate it if it> does not exist. It can be deleted any time, and indeed must be deleted> if packages are added (or they will not be found). This is arguably a bug,> but then all the scripts were never intended to be a general user interface> for CM3 users (only for the maintenance).> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:34:08 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:34:08 +0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: I strongly suggest that at least in some contexts, no padding ever be quietly inserted, and that all seeming need for padding generate an error, unless explicitly quashed, preferably by explicit insertion of padding fields by the programmer, and/or rearrangement sorted by size, or possibly some annotation of the overall struct/record/class/module, an annotation such as <* silent padding ok*>. Alignment issues really bug me... I realize many data structures are only ever seen in memory, by one process, so it doesn't matter, but when it matter, the languages/tools seem to fall down. As well, "padding" fields should be annotated as such and the compiler warn or error if they aren't needed. It's just dumb that code like: struct { int32 a; int64 b;}; when defining some stable important binary layout can have a varying but silently allowed meaning based on command line switches or targets.. Yes, I'm a dumb programmer to write it, but man the tools are lagging. This will fall on deaf ears and far from sufficient ears even if they were hearing. It's the C compilers that are somewhat broken here imho. C is unnecessarily broken here. Imho it's a big cause for headaches and easily solved....it doesn't have to stink so badly, if anyone cared.. I have had to maintain structs that had to look the same across different targets and therefore insert target-dependent padding. Ok, but it should have been easier. When I was done, I put in compile time asserts as to the offset of every single field so the next guy would have an easier time, and assiduously commented every byte of padding in the struct and its target-dependentness.... This was like for shared memory. Grumble, - Jay > From: darko at darko.org> To: rodney.bates at wichita.edu> Date: Tue, 12 Feb 2008 15:37:52 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] <*LAZYALIGN*>> > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures.> > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:> > > It sounds like all that Mac OS X needs is for _all_ types in an entire> > program to use the liberal packing rules. Have I understood > > correctly?> > I would have no grief over that.> >> > Darko wrote:> >> The liberalised alignment rules are required for the native Mac OS > >> X API and should stay. You cannot use that API without them. I > >> think the pragma is not required and can be removed. I agree with > >> all the points you make. The effect of the modified alignment > >> rules it to allow *packed* structures to have members aligned on > >> byte boundaries. This has the effect of packing the fields in the > >> tightest arrangement allowed by the platform. This might affect > >> performance, but if the user is concerned about this they should > >> specify field bit sizes that deliver improved performance. I don't > >> see a need to specify this on a structure level, for the reasons > >> you give and because the difference isn't significant enough in > >> the case of packed structures and their physical layout and > >> restrictions are platform dependent anyway.> >> I might also add that the alignment code is currently broken on > >> I386_DARWIN.> >> - Darko> >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote:> >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it> >>> being used anywhere?> >>>> >>> It is not documented in pragmas.html. The compiler front end > >>> appears> >>> to accept it. (In fact, Decls.m3 contains constants that suggest> >>> limitations on what declarations the pragma can appear on, but these> >>> are not actually enforced.) It liberalizes the alignment rules,> >>> generally allowing scalars to start on any byte boundary.> >>>> >>> Pickles have to be able to reconstruct the layout of types as the> >>> compiler would have done it for a machine (on which a now-being-read> >>> pickle was written) with different word size and alignment > >>> properties.> >>> Currently, pickles are completely unaware of lazy alignment. It> >>> would have to be encoded in type descriptions generated by the > >>> compiler> >>> using TipeDesc and read by pickles using RTTipe.> >>>> >>> Most troubling to me is what looks like a linguistic Pandora's box.> >>> The pragma can be associated with any constant, variable, or type> >>> _declaration_ (not type definition), with the result that different> >>> values of the same type can actually be different in their alignment> >>> rules and thus their layout. Similarly for different identifiers> >>> equated to the same type. Although the effects of this could > >>> possibly> >>> be hidden from the programmer in purely safe code, not so with > >>> unsafe> >>> code. I haven't thoroughly thought this through, but seems to me > >>> to> >>> really fly in the face of the whole typing philosophy of the > >>> language.> >>>> >>> For example, if pickles were to read in an object value, and there> >>> were >1 variants of the object's type in the reading program, > >>> differing> >>> only in the alignment rules, how would it decide which one to build?> >>> In fact, ignoring pickles altogether and just looking at a single > >>> program,> >>> if the object's type doesn't actually uniquely give its memory > >>> layout,> >>> how can it be accessed correctly?> >>>> >>> Additionally, a quick look at the compiler suggests it won't > >>> generate> >>> correct code for whole record assignment when the LHS and RHS are > >>> the> >>> same type but have different alignment characteristics.> >>>> >>> The more I think about it, it seems the only workable > >>> possibilities are:> >>>> >>> 1) Require the pragma to be associated only with a type > >>> _definition_ not a> >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > >>> this a> >>> property of the type that propagates to all names for the type and> >>> all variables, constants, etc. Also, this would make this property> >>> a part of the type signature that pickles uses when reading, -OR-> >>>> >>> 2) Forget it altogether.> >>>> >>> What do people think?> >>> -- > >>> -------------------------------------------------------------> >>> 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> >> > -- > > -------------------------------------------------------------> > 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> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:50:00 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:50:00 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Message-ID: I insist that it depends. Putting every platform-specific piece of code in its own file/directory can lead to mass duplication of nearly identical code. Sometimes an #if here or there goes very far in /improving/ code maintainability. A lot of #if here there and everywhere of course can have the opposite effect. And I realize if you were to drop support for a target, it is easier to find/delete files/directories than #ifs, but I don't think that's a good enough reason to sway the decision. It goes both ways. Yes, you could endeavor factor things down so that everything common is in common, and everything not-common is in platform-specific. But this is inadequate I think. The tail is wagging the dog unnecessarily I think. If my code very nearly all goes together, don't make me separate it. Also sometimes a different factoring is "encouraged" for other reasons, to match someone else's factoring. Look at the C*.i3 files. They actually can be almost all be nearly the same, yet they are hardly shared at all. I realize you could also do a sort of "forwarding", though I'm not sure that Modula-3 offers all the right capabilities for this. Type forwarding, sure. But how about procedure forwarding? Like nt386\cstdio.i3 fopen = common\ccommonstdio.i3 fopen? And having to duplicate a line per type/procedure is lame anyway, you KIND OF want "module inheritance". However, if you allow preprocessing based on target, perhaps the need for that goes away. While extern C varargs functions are generally useless in Modula-3, and therefore extern __cdecl is fairly rare, it DOES occur when you write little helpers in C, such as for errno. A good /heuristic/ might be to change the default in any directory that has no c_source. But it is only heuristic. Whatever is done here, some allowance should probably be made for multiple calling conventions in the same file. Switching the default to the overwhelming majority and then annotating the minority is reasonable. I still believe that silently ignoring calling conventions on all but NT386 is VERY reasonable, and that no other platform from here on out will ever have calling conventions. Esp. not with the same names. When OS/FOO has the FOOAPI calling convention, you can just ignore that one on all but target OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ugly something like: <*EXTERN FOOAPI WINAPI*> fopen(); FOOAPI for OS/FOO, WINAPI ignored. WINAPI for NT386, FOOAPI ignored. The One True Calling Convention for all others, calling convention ignored. I really believe this is highly highly unlikely to occur, and it is not a terrible outcome, and this bridge could be crossed in the far off future. The functions that are usually in need of calling conventions are usually only present on one system. Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly nonexistant. That could be also. A change just for ODBC is probably not the best, though it is a very small safe harmless change (I always say that :) ) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 2008 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform specific code > > should be in a separate file. I'd also like to see an option to > > move calling conventions to the makefile rather than in pramas to > > avoid having to duplicate interface files just to have a different > > calling convention for a different platform.> >> > - Darko> >> >> > On 12/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this through.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good > >> idea.> >>> >> Something like either the ability to prefix pragmas with a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Something like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worms.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expressions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >> etc.> >>> >> I don't really have enough interest here to work through this, > >> just sending out the bait...> >>> >> Obviously this was triggered by my happening into the odbc > >> directory and bringing up ignoring WINAPI on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> This reminds me of an important point here however -- nobody else > >> is going to make the mistake of ever having multiple calling > >> conventions. Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> >> Unless Mac68K support is added.> >>> >> And here is some rationale even. The PC and Mac evolved from > >> "small" systems, where assembly programming was common, more > >> people knew more lower level details and playing games with > >> calling conventions was something anyone could do. Most other > >> current systems are rooted in C programming. Working in C, calling > >> conventions are generally in a hidden layer below what anyone > >> thinks about. Therefore, the smaller number of capable people > >> working at that level have the good sense to only have one calling > >> convention. No more systems will evolve from "small", at least not > >> without having observed this history. Therefore, there will no > >> longer be multiple calling conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >> only x86> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 13:05:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 13:05:56 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Hi again, the builds I started again this morning before leaving home seem to have succeeded again. I don't understand why compilation with the latest sources on my own system was broken though; I'll have to check that tonight. There's seems to be no immediate need for action though :-) It would be great if all committers would check the tinderbox status on http://www.opencm3.net at least after check-ins. You'll find it under "Status -> Tinderbox Tests", or directly at http://tinderbox.elegosoft.com/tinderbox/cm3/status.html. It contains links to all the build logs and the m3tests and package build test results, as well as a list of check-ins that may be responsible for any breakage (click on the dates in the left column). Olaf Quoting Olaf Wagner : > Tonight some of the tinderbox builds failed for CM3. First I thought > it was just these changes to FilePosix which had already been fixed: > > ---------------------------- > revision 1.8 > date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: > +1 -1; commitid: pvCLLyqdDKQm24Rs; > This checkin fixes something Jay left behind. > > Please check things build on platforms other than yours before making > changes. The VAL is necessary on some targets because 0 is INTEGER whereas > result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly > compared with an INTEGER (result). The VAL is how we do the conversion to > LONGINT. > > On platforms where Utypes.off_t is INTEGER this code will work the same as it > is. > ---------------------------- > revision 1.7 > date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs; > more cygwin header cleanup, various dead types were used > in further dead types in Ushm.i3; go ahead and delete > dead stuff instead of commenting out > remove seemingly unnecessary VAL() that fails to compile > > but when I try to build now on my FreeBSD system, I get this from cm3: > > % ./m3-sys/cm3/FreeBSD4/cm3 -version > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 > *** > > ^C > > Please check all the latest commits carefully and back out anything > that seems suspicious or has not been tested. > > Thanks, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Tue Feb 12 13:56:02 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 04:56:02 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." Message-ID: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Can you just generate the Modula-3 code you want using a Python script or COBOL or whatever you like instead of trying to foist preprocessing nastiness on innocent users of high-level Modula-3? Preprocessing is super nasty. It's not just a question of human readability. m3tk has to be able to read the code, too. I should be able to write a program that reads in (using m3tk) an arbitrary Modula-3 interface and understands it to the point that it can generate Network Object stubs, inter-language call stubs, etc. The stubs should ALSO be human- and m3tk-readable after the transformation! This should work even if the programmer has been very "clever" in his use of Modula-3 constructs. (Just try getting something like that to work with C or C++... it's hopeless once the preprocessor gets involved, and possibly before.) Also if I may make a little request, if at all possible, please try not to break binary compatibility with gcc-compiled C and Fortran on NT386GNU (not sure if your ideas about calling conventions could possibly do that...) Mika Jay writes: >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I insist that it depends. >Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code. >Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility. >A lot of #if here there and everywhere of course can have the opposite effe= >ct. >And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision. >It goes both ways. >=20 >Yes, you could endeavor factor things down so that everything common is in = >common, and everything not-common is in platform-specific. But this is inad= >equate I think. The tail is wagging the dog unnecessarily I think. If my co= >de very nearly all goes together, don't make me separate it. Also sometimes= > a different factoring is "encouraged" for other reasons, to match someone = >else's factoring. Look at the C*.i3 files. They actually can be almost all = >be nearly the same, yet they are hardly shared at all. I realize you could = >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >l the right capabilities for this. Type forwarding, sure. But how about pro= >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is lame anyway, you = >KIND OF want "module inheritance". However, if you allow preprocessing base= >d on target, perhaps the need for that goes away. >=20 >While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno. >=20 >A good /heuristic/ might be to change the default in any directory that has= > no c_source. >But it is only heuristic. >=20 >Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file. >Switching the default to the overwhelming majority and then annotating the = >minority is reasonable. >=20 >I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like: ><*EXTERN FOOAPI WINAPI*> fopen(); >FOOAPI for OS/FOO, WINAPI ignored. >WINAPI for NT386, FOOAPI ignored. >The One True Calling Convention for all others, calling convention ignored. >=20 >I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future. >The functions that are usually in need of calling conventions are usually o= >nly present on one system. >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant. >That could be also. >A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) ) >=20 >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e= >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20= >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:= >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform= > specific code > > should be in a separate file. I'd also like to see an op= >tion to > > move calling conventions to the makefile rather than in pramas = >to > > avoid having to duplicate interface files just to have a different >= > > calling convention for a different platform.> >> > - Darko> >> >> > On 1= >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug= >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good= > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit= >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi= >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >= >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm= >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >= > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr= >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >= >> etc.> >>> >> I don't really have enough interest here to work through thi= >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b= >y my happening into the odbc > >> directory and bringing up ignoring WINAPI= > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >This reminds me of an important point here however -- nobody else > >> is g= >oing to make the mistake of ever having multiple calling > >> conventions. = >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> = >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.= > The PC and Mac evolved from > >> "small" systems, where assembly programmi= >ng was common, more > >> people knew more lower level details and playing g= >ames with > >> calling conventions was something anyone could do. Most othe= >r > >> current systems are rooted in C programming. Working in C, calling >= > >> conventions are generally in a hidden layer below what anyone > >> thin= >ks about. Therefore, the smaller number of capable people > >> working at t= >hat level have the good sense to only have one calling > >> convention. No = >more systems will evolve from "small", at least not > >> without having obs= >erved this history. Therefore, there will no > >> longer be multiple callin= >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does= > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I insist that it depends.
>Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code.
>Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility.
>A lot of #if here there and everywhere of course can have the opposite effe= >ct.
>And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision.
>It goes both ways.
> 
>Yes, you could endeavor factor things down so that everything common i= >s in common, and everything not-common is in platform-specific. But this is= > inadequate I think. The tail is wagging the dog unnecessarily I think. If = >my code very nearly all goes together, don't make me separate it. = >;Also sometimes a different factoring is "encouraged" for other reasons, to= > match someone else's factoring. Look at the C*.i3 files. They actually can= > be almost all be nearly the same, yet they are hardly shared at all. I rea= >lize you could also do a sort of "forwarding", though I'm not sure that Mod= >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu= >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco= >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la= >me anyway, you KIND OF want "module inheritance". However, if you allow pre= >processing based on target, perhaps the need for that goes away.
> 
>While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno.
> 
>A good /heuristic/ might be to change the default in any directory that has= > no c_source.
>But it is only heuristic.
> 
>Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file.
>Switching the default to the overwhelming majority and then annotating the = >minority is reasonable.
> 
>I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like:
><*EXTERN FOOAPI WINAPI*> fopen();
>FOOAPI for OS/FOO, WINAPI ignored.
>WINAPI for NT386, FOOAPI ignored.
>The One True Calling Convention for all others, calling convention ignored.= >
> 
>I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o= >nly present on one system.
>Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant.
>That could be also.
>A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) )
> 
> 
> - Jay

> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c= >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&= >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g= >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro= >te:
>
> > I think it's not a good idea. I think all platfor= >m specific code
> > should be in a separate file. I'd also like t= >o see an option to
> > move calling conventions to the makefile r= >ather than in pramas to
> > avoid having to duplicate interface f= >iles just to have a different
> > calling convention for a differ= >ent platform.
> >
> > - Darko
> >
> >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >;> So I have NOT thought this through.
> >>
> >>= > I wonder if "preprocessing" dependent only on "target" is a good
> = >>> idea.
> >>
> >> Something like either the = >ability to prefix pragmas with a target,
> >> or an "iftarget"= > and "ifnottarget" pragma.
> >>
> >> Something like= > so:
> >>
> >> <* IF_TARGET NT386 *>
> = >>> <* END_IF_TARGET*>
> >>
> >>
>= > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*= >>
> >> It's a small can of worms.
> >> Where can= > they be placed? Only at "global" scope? (ie: toplevel in
> >>= > an interface/module).
> >>
> >> What about IF_OSTY= >PE?
> >> What about expressions?
> >> IF_TARGET NT3= >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>= >; >>
> >> etc.
> >>
> >> I don't = >really have enough interest here to work through this,
> >> ju= >st sending out the bait...
> >>
> >> Obviously this= > was triggered by my happening into the odbc
> >> directory an= >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c= >alling conventions with a target.
> >>
> >> This re= >minds me of an important point here however -- nobody else
> >>= >; is going to make the mistake of ever having multiple calling
> >= >;> conventions. Therefore the generality of prefixing WINAPI with
&g= >t; >> NT386: is useless.
> >> Unless Mac68K support is ad= >ded.
> >>
> >> And here is some rationale even. The= > PC and Mac evolved from
> >> "small" systems, where assembly = >programming was common, more
> >> people knew more lower level= > details and playing games with
> >> calling conventions was s= >omething anyone could do. Most other
> >> current systems are = >rooted in C programming. Working in C, calling
> >> convention= >s are generally in a hidden layer below what anyone
> >> think= >s about. Therefore, the smaller number of capable people
> >> = >working at that level have the good sense to only have one calling
>= > >> convention. No more systems will evolve from "small", at least no= >t
> >> without having observed this history. Therefore, there = >will no
> >> longer be multiple calling conventions.
> &= >gt;>
> >> That is my theory at least.
> >>
&g= >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall= > is
> >> only x86
>


Climb to the top= > of the charts!=A0Play the word scramble challenge with star power. =3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin= >k_jan' target=3D'_new'>Play now! >= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- From jayk123 at hotmail.com Tue Feb 12 14:18:18 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:18:18 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika, I'm not going to change the default calling convention. Don't worry. At "best", try it out, measure it, and then provide pragmas/command line switches if folks want largescale change, but never by default, and even command line switch could be dangerous..the safe form is it'd only affect implemented implementation in a directory with a particular m3makefile directive, it would not affect imported implementations. And this is way way way down any nonexistant list.. Probably more interesting than more efficient but "canonical" calling conventions is "whole program optimization" like cross "module (source file) inlining, custom calling conventions, cross function constant propagation, etc. Stuff all left to gcc. :) Moving to AMD64 will make this go away quite nicely. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:23:26 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:23:26 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <47B11DC9.1040902@wichita.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> <47B11DC9.1040902@wichita.edu> Message-ID: <20080212132326.GA22149@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > I don't think this is what Tony meant. In C++, an opening brace > starts a block, but every local declaration in that block has its own > unique scope that only starts at that declaration and goes to the end > of the block. This is particularly messy because the local declarations > of a block need not all precede all the statements, That is, in my opinion, one of the few things that C and C++ did right, well, almost right. It permits a coding style in which every variable declaration is initialised, and is declared if and only if it has a value. Now that's a useful property. It fails for recursion, so there are limits in how far it can apply. And when coding like this, you want the simplest syntax to define a constant identifier -- one whose value cannot be rebound except by reexecuting the entire block. Making something that can change should require more effort -- like adding a keyword "var" or some such. It's amazing how many identifiers end up fitting this constraint, yielding very little visual ambiguity as to whether the value of a variable has changed since initialisation. This tends to be the style in functional languages. In my opinion, functional-style languages would benefit from detailed static typing (as detailed as Modula 3) and some imperative features, like assignment to things that are explicitly declared as being variable. While rarely needed (but usually at least a few times per program), doing completely without imperative features I consider an exercise in masochism. But I can't see any way that this would fit seamlessly into Modula 3 syntax. -- hendrik > and even worse > because the distinction between declarations and statements is extremely > subtle and, unless things have changed, never actually defined. > > (Do you remember Stroustrup's famous quote when taken to task about this? > "If it looks like a declaration, it's a declaration. If it looks like a > statement, it's a statement. If it doesn't look like either, it's a > syntax error.") Last time I looked at it (when I was involved in a C++ implementation a decade or more ago) the rule was "If it looks like a declaration, it's a declaration; *otherwise* if it looks like a statement, it's a statement.", with precise constraints on what contextual information the compiler was allowed to look at when deciding what it looked like. The only correct way I found to implement this was to parse every statement-declaration-like thing first as a declaration, and, if that failed, as a statement. It was a mess. -- hendrik > In contrast, in Modula-3, the scope of every local declaration > starts at the beginning of the block and ends at the end of the > block. A simple rule, but, in my opinion, a little too simple. > > The C++ reference makes an attempt at defining different terms for the > entire block and the region where the identifier can be referred-to, i.e., > from declaration to end of block (which I have called "scope" here). > But as I recall, they ended up carefully defining their terminology in > one section but then not using it consistently in the rest of the > language definition. Their heart wasn't really into it, was it? Much rather let the implementation define the language. -- hendrik From mika at async.caltech.edu Tue Feb 12 14:41:31 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 05:41:31 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> Message-ID: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: >> I don't think this is what Tony meant. In C++, an opening brace >> starts a block, but every local declaration in that block has its own >> unique scope that only starts at that declaration and goes to the end >> of the block. This is particularly messy because the local declarations >> of a block need not all precede all the statements, > >That is, in my opinion, one of the few things that C and C++ did right, >well, almost right. It permits a coding style in which every >variable declaration is initialised, and is declared if and only if it You can do all kinds of fun stuff with C's declarations/initializations. switch (a) { int x=7; case 0: use(x); /* oops */ ... } goto somewherefun; { int y=7; somewherefun: use(y); /* oops again */ } >has a value. Now that's a useful property. It fails for recursion, >so there are limits in how far it can apply. And when coding like this, >you want the simplest syntax to define a constant identifier -- one >whose value cannot be rebound except by reexecuting the entire block. >Making something that can change should require more effort -- like >adding a keyword "var" or some such. Sounds to me like you're talking about Modula-3's WITH! Mika From jayk123 at hotmail.com Tue Feb 12 14:50:22 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:50:22 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika good point, I know that, forgot, thanks for reminding me. One of the interesting things about Modula-3, or rather anything but C and C++, is easy parsing, easy building of other tools. Just to be clear though, independent of my crazy ideas, such tools can't just enumerate a source tree. I guess they should operate over the pkg tree? You know, they can't understand the source tree without understanding m3makefiles. I started a little experiment here. I added m3-libs/m3core/src/C/common/Cstdio.i3. This is a file that ought to be nearly identical for all targets. For now I only changed NT386. I'm thinking either: a) I'm not quite on base and just fork it per-target, as it was b) provide a little bit of C code with #ifdefs, like making the SEEK_* constants into VARs and using C to initialize them. That's a bit of a downer though, since constants ought to be constants. c) factor it somehow as I was alluding, like, well, again I'm not sure Modula-3 has what I'd want here, but at least for types and constants, you can push the non-portable stuff into Ctargetstdio.i3 and then expose them in Cstdio.i3, forking only Ctargetstdio.i. I'll explain so I can get my question in. :) I understand, say: Ctargetstdio.i3 (* one of these per target, with not much content *) CONST SEEK_CUR = ..; (* target specific probably *) SEEK_SET = ..; ditto SEEK_END = ..; ditto TYPE FOO = ... ditto Cstdio.i3 (* portable *) CONST SEEK_CUR = Ctargetstdio.SEEK_CUR; SEEK_SET = Ctargetstdio.SEEK_SET; SEEK_END = Ctargetstdio.SEEK_END; TYPE FOO = Ctargetstdio.FOO; FILE = UNTRACED REF RECORD END; procedure fopen(a: const_char_star; b: const_char_star): FILE; It is tedious but I believe it works. It'd be nice, I think, if every symbol in one interface could be automatically aliases/exposed in another. At least for this purpose, maybe not for any other. I'm speculating here, so please respond kindly. :) The non portable types and constants can be pushed out and then reexposed as if they were portable and in one place. However, let's say, for argument/question's sake, that some function accepts int on some targets, off_t on another. Nevermind for now how you can portably call it. Ctargetstdio.i3 (* one of these for every target, but another question in a sec ... *) PROCEDURE seeksomething(a: off_t); let's say it is int on some platforms. Cstdio.i3 (* the portable one *) seeksomething = Ctargetstdio.seeksomething; does this work? I should try it out, read the docs. But then the next question would be, let's say there's 20 platforms and 5 use off_t and 15 use int. It's unfortunate if I have to repeat the content 20 times when there are only two variants. You can see this kind of thing where sometimes we include_dir(TARGET), sometimes include_dir(OS_TYPE). OS_TYPE implies less work, nice. Perhaps concatening stuff in arbitrary way with Quake really is the way? It seems almost sarcastic, but perhaps not. As long as the pkg store is easily parsed? (There's a setting to ship implementation files. I guess that must be left on? I thought it'd be nice to reduce distribution size..) But for that matter --- could be processed by the compiler and result in a file with it already accounted for and ship that. Isn't that just as good? EXCEPT that more thought would have to go into the spec, whereas m3makefile is already a general purpose system that anyone can do anything with? ?? - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:52:05 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:52:05 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <20080212135205.GC22149@topoi.pooq.com> On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > >> I don't think this is what Tony meant. In C++, an opening brace > >> starts a block, but every local declaration in that block has its own > >> unique scope that only starts at that declaration and goes to the end > >> of the block. This is particularly messy because the local declarations > >> of a block need not all precede all the statements, > > > >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations. > > switch (a) { > int x=7; > case 0: > use(x); /* oops */ > ... > } > > goto somewherefun; > > { > int y=7; > > somewherefun: > use(y); /* oops again */ > } That's more a problem with C's control structures. Each case should be a block of its own. The bits outside any case shouldn't be there. etc., etc. > > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such. > > Sounds to me like you're talking about Modula-3's WITH! Close, except for syntax. If you use WITH in the stype I'm advocating you end up with extremely deep syntactic nesting, and you indent off the side of the page. Also, the whole WITH syntax is quite heavy. -- hendrik From jayk123 at hotmail.com Tue Feb 12 15:02:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:02:23 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: C++ fixes this sort of thing. goto around initialization is an error. C++ constructors and destructors are a really good thing -- can't forgot to initialize or cleanup stuff. Very much like try/finally, but the finally code is better "positioned". Rather than special case memory with some fancy garbage collector, provide a mechanism for any type. RAII and all that. It's a very good theory at least. However I've become uncertain of it. Could be that a huge part of it is ok, if only you could train everyone in RAII and constructors/destructors. But then there are close pesky fopen/fclose/malloc/free you have to get rid of. And a lot of complexity around templates, unrelated, but can you allow C++ in a codebase but rigorously ban certain aspects? Maybe draw an analogy to Itanium. Lots of obviously good features, not even all that novel. But must we really combine them all together all at once? (register windows a la SPARC, loop unrolling a la any decent compiler..) And maybe memory is really vastly more interesting than other resources?Oh, and locks, special case those too... Mika your switch example, besides being invalid C++, is just not fair. I don't think people even think to write their code like that. Introducing variables at the top of a switch is rare, esp. initializing them. That C allows variables declared anywhere, and open braces anywhere, seems little known and little taken advantage of. Everyone just moves all the locals to the top, and either programmers do careful static flow analysis, or "lazily" (but reasonably) "over initialize" things, like maybe to 0 or { 0 }. C++ is what really fixes this properly and people know and understand it. Declare stuff anywhere, closest to first, use, and preferably initialized or a user defined type with a constructor. EXCEPT that it doesn't play nicely with goto, and if you aren't using exceptions, then goto is the next best thing...so then you are forced into something closer to the C style, though you gain constructors to help some. And hopefully the compiler can optimize away a lot of the unnecessary initialization... Java and I presume C# have a nice feature here too where they require the compiler to error for use of uninitialized variables, though I suspect the specced algorithm misses some things, like: if (...) initialize x common code if (same thing) use x <== possible use of uninitialize x, not At least I've seen other tools (not Java/C# compilers, I don't use those) get confused by this.. - Jay > To: hendrik at topoi.pooq.com> Date: Tue, 12 Feb 2008 05:41:31 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > hendrik at topoi.pooq.com writes:> >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> >> I don't think this is what Tony meant. In C++, an opening brace> >> starts a block, but every local declaration in that block has its own> >> unique scope that only starts at that declaration and goes to the end> >> of the block. This is particularly messy because the local declarations> >> of a block need not all precede all the statements,> >> >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations.> > switch (a) {> int x=7;> case 0:> use(x); /* oops */> ...> }> > goto somewherefun;> > {> int y=7;> > somewherefun:> use(y); /* oops again */> }> > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such.> > Sounds to me like you're talking about Modula-3's WITH!> > Mika _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 15:05:46 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:05:46 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080212135205.GC22149@topoi.pooq.com> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: Agreed! C++ vs. WITH, C++ wins by not indenting unnecessarily. See that change I was fiddling with in Time.m3 for examle. Hm. Can we get consensus on a language change? :) BEGIN VAR a := 1; IO.PutInt(a); VAR b := 2, (* ? *) c := 3; (* ? *) IO.PutInt(b); ? Easier to require "VAR" on each, a bit wordy. - Jay > Date: Tue, 12 Feb 2008 08:52:05 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote:> > hendrik at topoi.pooq.com writes:> > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> > >> I don't think this is what Tony meant. In C++, an opening brace> > >> starts a block, but every local declaration in that block has its own> > >> unique scope that only starts at that declaration and goes to the end> > >> of the block. This is particularly messy because the local declarations> > >> of a block need not all precede all the statements,> > >> > >That is, in my opinion, one of the few things that C and C++ did right, > > >well, almost right. It permits a coding style in which every > > >variable declaration is initialised, and is declared if and only if it > > > > You can do all kinds of fun stuff with C's declarations/initializations.> > > > switch (a) {> > int x=7;> > case 0:> > use(x); /* oops */> > ...> > }> > > > goto somewherefun;> > > > {> > int y=7;> > > > somewherefun:> > use(y); /* oops again */> > }> > That's more a problem with C's control structures. Each case should be > a block of its own. The bits outside any case shouldn't be there. > etc., etc.> > > > > > > >has a value. Now that's a useful property. It fails for recursion, > > >so there are limits in how far it can apply. And when coding like this, > > >you want the simplest syntax to define a constant identifier -- one > > >whose value cannot be rebound except by reexecuting the entire block. > > >Making something that can change should require more effort -- like > > >adding a keyword "var" or some such.> > > > Sounds to me like you're talking about Modula-3's WITH!> > Close, except for syntax. If you use WITH in the stype I'm > advocating you end up with extremely deep syntactic nesting, and you > indent off the side of the page. Also, the whole WITH syntax is quite > heavy.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 16:57:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 15:57:25 +0000 Subject: [M3devel] utime.i3 and imported data Message-ID: For good reason, imported (dynamically linked) data doesn't work great on Win32. Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];} for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 17:27:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 16:27:38 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: sorry, still not a bad idea, but not where my crash is. I wasn't paying close enough attention. Those aren't used on NT386GNU. The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone); I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:07:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:07:24 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: well..we were accessing fields at the end of struct tm that aren't there..switched from DateBsd to DateLinux and now my exact first proposal stands. :) I worked around but it is lame, imho more lame than my suggestion. My suggestion still imports/shares the data, just via a C function call, so that the right declarations are present. The right declarations are..difficult in Modula-3. You'd have to declare the variables as pointers and change their name, and then somehow either layer portable code over that, or fork DateBsd/DateLinux to DateCygwin..which I just don't think is worth it. I don't like per-platform forks, too much duplicity, too much multiplication out of code, too much code, too much cruft, too little maintenance.... better to merge stuff if it isn't a mess and have less overall source code to maintain.... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] utime.i3 and imported dataDate: Tue, 12 Feb 2008 16:27:38 +0000 sorry, still not a bad idea, but not where my crash is.I wasn't paying close enough attention. Those aren't used on NT386GNU.The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone);I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:21:15 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:21:15 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: I think I just said this over the weekend, but really, I should be able to put in modules and not be forced to put them in an interface. Look at the cygwin Utime.i3/m3/C.c for example... Yeah, it's a workaround, that I'd like to remove, but it could easily represent a non-workaround.. There's no real "interface/module" here, it's just that I wrote some of the code in C. sorry to be such an annoying whiner..but I ran into this multiple times over a short span of time... - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:26:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:26:24 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: Jay, Modula-3 has a perfectly good way of saying what you want as PACKED types. Whether they are fully implemented or not is another question. -- Tony On Feb 12, 2008, at 6:34 AM, Jay wrote: > I strongly suggest that at least in some contexts, no padding ever > be quietly inserted, and that all seeming need for padding generate > an error, unless explicitly quashed, preferably by explicit > insertion of padding fields by the programmer, and/or rearrangement > sorted by size, or possibly some annotation of the overall struct/ > record/class/module, an annotation such as <* silent padding ok*>. > Alignment issues really bug me... > I realize many data structures are only ever seen in memory, by one > process, so it doesn't matter, but when it matter, the languages/ > tools seem to fall down. > As well, "padding" fields should be annotated as such and the > compiler warn or error if they aren't needed. > > It's just dumb that code like: > > struct > { > int32 a; > int64 b; > }; > > when defining some stable important binary layout can have a > varying but silently allowed meaning based on command line switches > or targets.. Yes, I'm a dumb programmer to write it, but man the > tools are lagging. > > This will fall on deaf ears and far from sufficient ears even if > they were hearing. > It's the C compilers that are somewhat broken here imho. > C is unnecessarily broken here. Imho it's a big cause for headaches > and easily solved....it doesn't have to stink so badly, if anyone > cared.. > > I have had to maintain structs that had to look the same across > different targets and therefore insert target-dependent padding. > Ok, but it should have been easier. When I was done, I put in > compile time asserts as to the offset of every single field so the > next guy would have an easier time, and assiduously commented every > byte of padding in the struct and its target-dependentness.... > This was like for shared memory. > > Grumble, > - Jay > > > > > From: darko at darko.org > > To: rodney.bates at wichita.edu > > Date: Tue, 12 Feb 2008 15:37:52 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] <*LAZYALIGN*> > > > > That's not quite right. Certain Mac API structures need to be > aligned > > to Motorola 68K alignment for historical reasons. All other > structures > > should use normal alignment to be compatible with C and Unix > > interfaces. The alignment change was implemented to be supported > only > > in packed structures as a natural and intuitive way to "force" > > alignment. You could view it as a bug fix to overly restrictive > > alignment rules in packed structures. > > > > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > > > > > It sounds like all that Mac OS X needs is for _all_ types in an > entire > > > program to use the liberal packing rules. Have I understood > > > correctly? > > > I would have no grief over that. > > > > > > Darko wrote: > > >> The liberalised alignment rules are required for the native > Mac OS > > >> X API and should stay. You cannot use that API without them. I > > >> think the pragma is not required and can be removed. I agree with > > >> all the points you make. The effect of the modified alignment > > >> rules it to allow *packed* structures to have members aligned on > > >> byte boundaries. This has the effect of packing the fields in the > > >> tightest arrangement allowed by the platform. This might affect > > >> performance, but if the user is concerned about this they should > > >> specify field bit sizes that deliver improved performance. I > don't > > >> see a need to specify this on a structure level, for the reasons > > >> you give and because the difference isn't significant enough in > > >> the case of packed structures and their physical layout and > > >> restrictions are platform dependent anyway. > > >> I might also add that the alignment code is currently broken on > > >> I386_DARWIN. > > >> - Darko > > >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > > >>> Does anybody know about the status of pragma <*LAZYALIGN*>? > Is it > > >>> being used anywhere? > > >>> > > >>> It is not documented in pragmas.html. The compiler front end > > >>> appears > > >>> to accept it. (In fact, Decls.m3 contains constants that suggest > > >>> limitations on what declarations the pragma can appear on, > but these > > >>> are not actually enforced.) It liberalizes the alignment rules, > > >>> generally allowing scalars to start on any byte boundary. > > >>> > > >>> Pickles have to be able to reconstruct the layout of types as > the > > >>> compiler would have done it for a machine (on which a now- > being-read > > >>> pickle was written) with different word size and alignment > > >>> properties. > > >>> Currently, pickles are completely unaware of lazy alignment. It > > >>> would have to be encoded in type descriptions generated by the > > >>> compiler > > >>> using TipeDesc and read by pickles using RTTipe. > > >>> > > >>> Most troubling to me is what looks like a linguistic > Pandora's box. > > >>> The pragma can be associated with any constant, variable, or > type > > >>> _declaration_ (not type definition), with the result that > different > > >>> values of the same type can actually be different in their > alignment > > >>> rules and thus their layout. Similarly for different identifiers > > >>> equated to the same type. Although the effects of this could > > >>> possibly > > >>> be hidden from the programmer in purely safe code, not so with > > >>> unsafe > > >>> code. I haven't thoroughly thought this through, but seems to me > > >>> to > > >>> really fly in the face of the whole typing philosophy of the > > >>> language. > > >>> > > >>> For example, if pickles were to read in an object value, and > there > > >>> were >1 variants of the object's type in the reading program, > > >>> differing > > >>> only in the alignment rules, how would it decide which one to > build? > > >>> In fact, ignoring pickles altogether and just looking at a > single > > >>> program, > > >>> if the object's type doesn't actually uniquely give its memory > > >>> layout, > > >>> how can it be accessed correctly? > > >>> > > >>> Additionally, a quick look at the compiler suggests it won't > > >>> generate > > >>> correct code for whole record assignment when the LHS and RHS > are > > >>> the > > >>> same type but have different alignment characteristics. > > >>> > > >>> The more I think about it, it seems the only workable > > >>> possibilities are: > > >>> > > >>> 1) Require the pragma to be associated only with a type > > >>> _definition_ not a > > >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > > >>> this a > > >>> property of the type that propagates to all names for the > type and > > >>> all variables, constants, etc. Also, this would make this > property > > >>> a part of the type signature that pickles uses when reading, - > OR- > > >>> > > >>> 2) Forget it altogether. > > >>> > > >>> What do people think? > > >>> -- > > >>> ------------------------------------------------------------- > > >>> 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 > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Tue Feb 12 18:33:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:33:01 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: This was to "fix" building NT386GNU because lseek was returning int or long instead of off_t. My mistake by changing the wrong side of things. The return type is fixed and NT386GNU is ok with the "VAL". - Jay From: jayk123 at hotmail.comTo: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.comSubject: val?Date: Tue, 12 Feb 2008 06:22:28 +0000 Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available.There is/was a compilation problem with what I was doing.I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:34:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:34:12 -0500 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: <8B40FF77-0AF5-4907-9935-03CEE1E24BB7@cs.purdue.edu> Thanks Jay and Olaf for your explanations. I am only ever a general user of the scripts, but perhaps as a maintainer I should understand them better. On Feb 12, 2008, at 5:34 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I notice scripts/PKGS is no longer in the repository. Does this get >> generated somehow now? I know that do-cm3-std.sh depends on it >> because >> my copy of PKGS was broken (missing sysutils). Can someone >> explain to >> me how the build scripts have changed and how I should be using them? > > PKGS has never been checked-in and should not as far as I know. > It contains workspace-dependent paths and is built by find-packages.sh > if I remember correctly. All shell scripts will generate it if it > does not exist. It can be deleted any time, and indeed must be deleted > if packages are added (or they will not be found). This is arguably > a bug, > but then all the scripts were never intended to be a general user > interface > for CM3 users (only for the maintenance). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 12 18:42:01 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:01 -0500 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Aren't these all superseded by gettimeofday? I say just not support the global variable access. Utime.i3 on other platforms does not have these globals. On Feb 12, 2008, at 12:07 PM, Jay wrote: > well..we were accessing fields at the end of struct tm that aren't > there..switched from DateBsd to DateLinux and now my exact first > proposal stands. :) > > I worked around but it is lame, imho more lame than my suggestion. > My suggestion still imports/shares the data, just via a C function > call, so that the right declarations are present. > The right declarations are..difficult in Modula-3. > You'd have to declare the variables as pointers and change their > name, and then somehow either layer portable code over that, or > fork DateBsd/DateLinux to DateCygwin..which I just don't think is > worth it. I don't like per-platform forks, too much duplicity, too > much multiplication out of code, too much code, too much cruft, too > little maintenance.... better to merge stuff if it isn't a mess and > have less overall source code to maintain.... > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] utime.i3 and imported data > Date: Tue, 12 Feb 2008 16:27:38 +0000 > > sorry, still not a bad idea, but not where my crash is. > I wasn't paying close enough attention. Those aren't used on NT386GNU. > The crash is probably here: > > C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): > date.zone := M3toC.CopyStoT (tm.tm_zone); > > I don't know why yet. (meta reason -- these time formats aren't > worthwhile even if forward slashes in paths and X Windows are....) > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Tue, 12 Feb 2008 15:57:25 +0000 > Subject: [M3devel] utime.i3 and imported data > > For good reason, imported (dynamically linked) data doesn't work > great on Win32. > Functions work much better. Data can work, but you generally need > the header to say __declspec(dllimport), to change it to a > declaration of a pointer. I've seen GNU ld has some workaround but > I'm not familiar with it, it doesn't worthwhile to me, and I'm > having a problem. > > I strongly suggest all the Utime.i3: > > <*EXTERNAL*> VAR timezone: time_t; > <*EXTERNAL*> VAR daylight: int; > <*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; > > be changed to functions: > > <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t; > <*EXTERNAL Utime__get_daylight*> get_daylight(): int; > <*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; > > > with an implementation in C: > > UtimeC.c > #include > time_t Utime__get_timezone(void) > { > return timezone; > } > > int Utime__get_daylight(void) > { > return daylight; > } > > char* Utime__get_tzname(unsigned a) > { > return tzname[a]; > } > > for now I'm going to try another workaround..where NT386GNU has > this data as not external and some C code to call tzset and then > copy the data from the C globals to Modula-3 globals. > > The datetime feature I added to Quake is crashing, I think due to > this... > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:42:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:57 -0500 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: The globals are gross, and not available on other platforms. Let's just drop them... On Feb 12, 2008, at 12:21 PM, Jay wrote: > I think I just said this over the weekend, but really, I should be > able to put in modules and not be forced to put them in an > interface. > Look at the cygwin Utime.i3/m3/C.c for example... > Yeah, it's a workaround, that I'd like to remove, but it could > easily represent a non-workaround.. > There's no real "interface/module" here, it's just that I wrote > some of the code in C. > > sorry to be such an annoying whiner..but I ran into this multiple > times over a short span of time... > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:43:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:43:53 -0500 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: The log tells the story much better than random comments in the code. On Feb 12, 2008, at 1:18 AM, Jay wrote: > I added some files a while ago and someone either complained or > added them, so I've been adding them since. > > - Jay > > > > Date: Tue, 12 Feb 2008 05:20:47 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 08/02/12 05:20:47 > > > > Modified files: > > cm3/m3-sys/cm3/src/: m3makefile > > > > Log message: > > Let's avoid RCS id stuff shall we. Just clutters up the files... > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Tue Feb 12 18:50:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:50:03 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: <98447784-CE9A-40E4-8305-DA711A0EEBE1@cs.purdue.edu> Hear hear! On Feb 12, 2008, at 7:56 AM, Mika Nystrom wrote: > > Can you just generate the Modula-3 code you want using a Python > script or COBOL or whatever you like instead of trying to foist > preprocessing nastiness on innocent users of high-level Modula-3? > > Preprocessing is super nasty. It's not just a question of human > readability. m3tk has to be able to read the code, too. I should > be able to write a program that reads in (using m3tk) an arbitrary > Modula-3 interface and understands it to the point that it can > generate Network Object stubs, inter-language call stubs, etc. The > stubs should ALSO be human- and m3tk-readable after the > transformation! > This should work even if the programmer has been very "clever" in > his use of Modula-3 constructs. (Just try getting something like > that to work with C or C++... it's hopeless once the preprocessor > gets involved, and possibly before.) > > Also if I may make a little request, if at all possible, please try > not to break binary compatibility with gcc-compiled C and Fortran > on NT386GNU (not sure if your ideas about calling conventions could > possibly do that...) > > Mika > > Jay writes: >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> I insist that it depends. >> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code. >> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility. >> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct. >> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision. >> It goes both ways. >> =20 >> Yes, you could endeavor factor things down so that everything >> common is in = >> common, and everything not-common is in platform-specific. But >> this is inad= >> equate I think. The tail is wagging the dog unnecessarily I think. >> If my co= >> de very nearly all goes together, don't make me separate it. Also >> sometimes= >> a different factoring is "encouraged" for other reasons, to match >> someone = >> else's factoring. Look at the C*.i3 files. They actually can be >> almost all = >> be nearly the same, yet they are hardly shared at all. I realize >> you could = >> also do a sort of "forwarding", though I'm not sure that Modula-3 >> offers al= >> l the right capabilities for this. Type forwarding, sure. But how >> about pro= >> cedure forwarding? Like nt386\cstdio.i3 fopen =3D common >> \ccommonstdio.i3 fo= >> pen? And having to duplicate a line per type/procedure is lame >> anyway, you = >> KIND OF want "module inheritance". However, if you allow >> preprocessing base= >> d on target, perhaps the need for that goes away. >> =20 >> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno. >> =20 >> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source. >> But it is only heuristic. >> =20 >> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file. >> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable. >> =20 >> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like: >> <*EXTERN FOOAPI WINAPI*> fopen(); >> FOOAPI for OS/FOO, WINAPI ignored. >> WINAPI for NT386, FOOAPI ignored. >> The One True Calling Convention for all others, calling convention >> ignored. >> =20 >> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future. >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system. >> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant. >> That could be also. >> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) ) >> =20 >> =20 >> - Jay >> >> >> >>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: >>> hosking at cs.purdue.e= >> du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, >> 11 Feb 20= >> 08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, >> 2008, at 8:= >> 37 PM, Darko wrote:> > > I think it's not a good idea. I think all >> platform= >> specific code > > should be in a separate file. I'd also like to >> see an op= >> tion to > > move calling conventions to the makefile rather than >> in pramas = >> to > > avoid having to duplicate interface files just to have a >> different >= >>> calling convention for a different platform.> >> > - Darko> >> >> >>> > On 1= >> 2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought >> this throug= >> h.> >>> >> I wonder if "preprocessing" dependent only on "target" >> is a good= >>>>> idea.> >>> >> Something like either the ability to prefix >>>>> pragmas wit= >> h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> >> Somethi= >> ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> >>> >>> >= >>> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can >>> of worm= >> s.> >> Where can they be placed? Only at "global" scope? (ie: >> toplevel in >= >>>> an interface/module).> >>> >> What about IF_OSTYPE?> >> What >>>> about expr= >> essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS >> (NT)> >>> >= >>> etc.> >>> >> I don't really have enough interest here to work >>> through thi= >> s, > >> just sending out the bait...> >>> >> Obviously this was >> triggered b= >> y my happening into the odbc > >> directory and bringing up >> ignoring WINAPI= >> on non-NT386 or > >> prefixing calling conventions with a target.> >> >>> >> = >> This reminds me of an important point here however -- nobody else >> > >> is g= >> oing to make the mistake of ever having multiple calling > >> >> conventions. = >> Therefore the generality of prefixing WINAPI with > >> NT386: is >> useless.> = >>>> Unless Mac68K support is added.> >>> >> And here is some >>>> rationale even.= >> The PC and Mac evolved from > >> "small" systems, where assembly >> programmi= >> ng was common, more > >> people knew more lower level details and >> playing g= >> ames with > >> calling conventions was something anyone could do. >> Most othe= >> r > >> current systems are rooted in C programming. Working in C, >> calling >= >>>> conventions are generally in a hidden layer below what anyone > >>>> >> thin= >> ks about. Therefore, the smaller number of capable people > >> >> working at t= >> hat level have the good sense to only have one calling > >> >> convention. No = >> more systems will evolve from "small", at least not > >> without >> having obs= >> erved this history. Therefore, there will no > >> longer be >> multiple callin= >> g conventions.> >>> >> That is my theory at least.> >>> >> Oh, >> Windows does= >> also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >> _________________________________________________________________ >> Climb to the top of the charts!=A0Play the word scramble challenge >> with sta= >> r power. >> http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlink_ja= >> n= >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> I insist that it depends.
>> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code.
>> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility.
>> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct.
>> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision.
>> It goes both ways.
>>  
>> Yes, you could endeavor factor things down so that everything >> common i= >> s in common, and everything not-common is in platform-specific. >> But this is= >> inadequate I think. The tail is wagging the dog unnecessarily I >> think. If = >> my code very nearly all goes together, don't make me separate >> it. = >> ;Also sometimes a different factoring is "encouraged" for other >> reasons, to= >> match someone else's factoring. Look at the C*.i3 files. They >> actually can= >> be almost all be nearly the same, yet they are hardly shared at >> all. I rea= >> lize you could also do a sort of "forwarding", though I'm not sure >> that Mod= >> ula-3 offers all the right capabilities for this. Type forwarding, >> sure. Bu= >> t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D >> common\cco= >> mmonstdio.i3 fopen? And having to duplicate a line per type/ >> procedure is la= >> me anyway, you KIND OF want "module inheritance". However, if you >> allow pre= >> processing based on target, perhaps the need for that goes away.
>>  
>> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno.
>>  
>> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source.
>> But it is only heuristic.
>>  
>> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file.
>> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable.
>>  
>> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like:
>> <*EXTERN FOOAPI WINAPI*> fopen();
>> FOOAPI for OS/FOO, WINAPI ignored.
>> WINAPI for NT386, FOOAPI ignored.
>> The One True Calling Convention for all others, calling convention >> ignored.= >>
>>  
>> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future.>> >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system.
>> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant.
>> That could be also.
>> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) )
>>  
>>  
>>  - Jay

>> >>
>>
>> > CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: >> hosking at c= >> s.purdue.edu
> Subject: Re: [M3devel] "target specific >> pragmas"?
&= >> gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: >> darko at darko.org
&g= >> t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, >> Darko wro= >> te:
>
> > I think it's not a good idea. I think >> all platfor= >> m specific code
> > should be in a separate file. I'd >> also like t= >> o see an option to
> > move calling conventions to the >> makefile r= >> ather than in pramas to
> > avoid having to duplicate >> interface f= >> iles just to have a different
> > calling convention for >> a differ= >> ent platform.
> >
> > - Darko
> >> >
> >> R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >> >
> >= >> ;> So I have NOT thought this through.
> >>
> >> >>= >> I wonder if "preprocessing" dependent only on "target" is a good >>
> = >> >> idea.
> >>
> >> Something like >> either the = >> ability to prefix pragmas with a target,
> >> or an >> "iftarget"= >> and "ifnottarget" pragma.
> >>
> >> >> Something like= >> so:
> >>
> >> <* IF_TARGET NT386 >> *>
> = >> >> <* END_IF_TARGET*>
> >>
> >> >>
>= >> >> <* IF_TARGET NT386 *>
> >> <* >> END_IF_TARGET*= >> >
> >> It's a small can of worms.
> >> >> Where can= >> they be placed? Only at "global" scope? (ie: toplevel in
> >> >>= >> an interface/module).
> >>
> >> What about >> IF_OSTY= >> PE?
> >> What about expressions?
> >> >> IF_TARGET NT3= >> 86 OR NTAMD64
> >>
> >> IF_TARGET STARTS >> (NT)
>= >> ; >>
> >> etc.
> >>
> >> >> I don't = >> really have enough interest here to work through this,
> >> >> ju= >> st sending out the bait...
> >>
> >> >> Obviously this= >> was triggered by my happening into the odbc
> >> >> directory an= >> d bringing up ignoring WINAPI on non-NT386 or
> >> >> prefixing c= >> alling conventions with a target.
> >>
> >> >> This re= >> minds me of an important point here however -- nobody else >>
> >>= >> ; is going to make the mistake of ever having multiple calling >>
> >= >> ;> conventions. Therefore the generality of prefixing WINAPI >> with
&g= >> t; >> NT386: is useless.
> >> Unless Mac68K >> support is ad= >> ded.
> >>
> >> And here is some rationale >> even. The= >> PC and Mac evolved from
> >> "small" systems, where >> assembly = >> programming was common, more
> >> people knew more >> lower level= >> details and playing games with
> >> calling >> conventions was s= >> omething anyone could do. Most other
> >> current >> systems are = >> rooted in C programming. Working in C, calling
> >> >> convention= >> s are generally in a hidden layer below what anyone
> >> >> think= >> s about. Therefore, the smaller number of capable people
> >> >> = >> working at that level have the good sense to only have one calling >>
>= >> >> convention. No more systems will evolve from "small", at >> least no= >> t
> >> without having observed this history. >> Therefore, there = >> will no
> >> longer be multiple calling >> conventions.
> &= >> gt;>
> >> That is my theory at least.
> >> >>
&g= >> t; >> Oh, Windows does also have __thiscall and __clrcall. >> __thiscall= >> is
> >> only x86
>


Climb to >> the top= >> of the charts!=A0Play the word scramble challenge with star power. >> > =3D'http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlin= >> k_jan' target=3D'_new'>Play now! >> = >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_-- From hosking at cs.purdue.edu Tue Feb 12 18:54:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:54:15 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212130518.F0C7B10D4659@birch.elegosoft.com> References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: Jay, I *really* dislike the idea that you are putting target-specific code in a subdirectory labeled Common! If I want to search for target-specific stuff I grep for directories labeled by that target. Please, please, please think about the global picture before making these sorts of local changes! Please back this change out and put this where it belongs in cm3/m3- libs/m3core/src/C/NT386. I am happy to do it for you but I have other things to do with my time! On Feb 12, 2008, at 2:05 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 14:05:18 > > Modified files: > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c > > Log message: > fix (NT386 only) From hosking at cs.purdue.edu Tue Feb 12 19:00:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 13:00:39 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212125650.7DE8D10D4659@birch.elegosoft.com> References: <20080212125650.7DE8D10D4659@birch.elegosoft.com> Message-ID: <3BDD1B0E-CD23-43D1-9BC0-7B36FE6024AF@cs.purdue.edu> The C stuff is not intended to expose a full C API to Modula-3 programmers. It is there mostly for bridging to C-based libraries, particularly platform-specific functionality for platforms that are implemented in C. Some of that bridging is done in the OS-specific unix subdirectories and some in the C subdirectories. Choosing where to put that bridge code is a matter of style I guess, but it should probably be a matter of consensus among the developers of CM3. So, do folks out there have any opinions on how to best structure these bridging portions of m3core? I would argue for the minimum needed to support core M3 functionality. Jay seems to want to throw everything including the kitchen sink into the core libraries. I would argue that doing so makes the job of maintaining and porting Modula-3 a little more onerous. On Feb 12, 2008, at 1:56 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 13:56:50 > > Added files: > cm3/m3-libs/m3core/src/unix/NT386/: Unix.i3 Uuio.i3 > > Log message: > a fair amount of "unix i/o" is directly provided by msvcr*.dll and > should perhaps be exposed /somewhere/. Here is a start, of sorts. From dragisha at m3w.org Tue Feb 12 18:58:44 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 18:58:44 +0100 Subject: [M3devel] wtf "code generation errors"? Message-ID: <1202839124.623.1.camel@faramir.m3w.org> % cm3 --- building in ../LINUXLIBC6 --- new source -> compiling Connection.i3 new source -> compiling Connection.m3 new source -> compiling PDU.i3 new source -> compiling PDU.m3 "../src/PDU.m3", line 107: warning: not used (len) "../src/PDU.m3", line 104: warning: not used (b) "../src/PDU.m3", line 116: warning: open array passed by value (o) "../src/PDU.m3", line 118: warning: not used (cStr) "../src/PDU.m3", line 116: warning: not used (b) "../src/PDU.m3", line 116: warning: not used (o) "../src/PDU.m3", line 160: warning: not used (c) "../src/PDU.m3", line 59: warning: not used (GetInt) 8 warnings encountered new source -> compiling SMPP.m3 "../src/SMPP.m3", line 1: 4 code generation errors 1 error encountered compilation failed => not building program "smpp" Fatal Error: package build failed -- Dragi?a Duri? From hendrik at topoi.pooq.com Tue Feb 12 20:13:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 14:13:38 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: <20080212191338.GA24578@topoi.pooq.com> On Tue, Feb 12, 2008 at 02:05:46PM +0000, Jay wrote: > Agreed! > C++ vs. WITH, C++ wins by not indenting unnecessarily. > See that change I was fiddling with in Time.m3 for examle. > > Hm. Can we get consensus on a language change? :) > > BEGIN VAR a := 1; > IO.PutInt(a); > VAR b := 2, (* ? *) > c := 3; (* ? *) > IO.PutInt(b); > > ? Easier to require "VAR" on each, a bit wordy. > > - Jay That would work. But I'd use CONST more than VAR (if I had a choice) And I'd like to be able to specify the type. I'm a fanatic about making types explicit. -- hendrik From hosking at cs.purdue.edu Tue Feb 12 21:05:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 15:05:43 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202839124.623.1.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: Did something change in m3middle/m3front lately? On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > % cm3 > --- building in ../LINUXLIBC6 --- > > new source -> compiling Connection.i3 > new source -> compiling Connection.m3 > new source -> compiling PDU.i3 > new source -> compiling PDU.m3 > "../src/PDU.m3", line 107: warning: not used (len) > "../src/PDU.m3", line 104: warning: not used (b) > "../src/PDU.m3", line 116: warning: open array passed by value (o) > "../src/PDU.m3", line 118: warning: not used (cStr) > "../src/PDU.m3", line 116: warning: not used (b) > "../src/PDU.m3", line 116: warning: not used (o) > "../src/PDU.m3", line 160: warning: not used (c) > "../src/PDU.m3", line 59: warning: not used (GetInt) > 8 warnings encountered > new source -> compiling SMPP.m3 > "../src/SMPP.m3", line 1: 4 code generation errors > 1 error encountered > compilation failed => not building program "smpp" > Fatal Error: package build failed > > -- > Dragi?a Duri? From rcoleburn at scires.com Tue Feb 12 21:16:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 12 Feb 2008 15:16:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <47B1B848.1E75.00D7.1@scires.com> Jay: My understanding of Modula-3 is that rather than cluttering up the source code with a bunch of preprocessor directives to deal with the various changes needed by various platforms, a separate source file is used for platforms whose implementation must diverge. The m3makefile is used to control the selection of these platform sources at build time. I like this approach much better. Regards, Randy >>> Jay 2/11/2008 8:21 PM >>> So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 12 22:12:45 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:12:45 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 13:50:22 GMT." Message-ID: <200802122112.m1CLCjU0006778@camembert.async.caltech.edu> Your seeksomething = Ctargetstdio.seeksomething should work. Another thing that might work well is to use generics. For instance, have some interfaces Win32Types.i3 MacOSTypes.i3 FreeBSDTypes.i3 And then build your other stuff as generics passing in OSTypes... of course you can't do *everything* with generics, but type variants you can do. About preprocessing. It's clear you're going to have variable code. When you deal with OS things, of course you will. Currently this variability is expressed in Quake. There's no way of getting away from a certain amount of variability as long as you're interfacing with an OS, I think we all know that. But there's a difference between doing it in Quake and in Modula-3, which is why I used the expression "foisting preprocessing on innocent users of high-level Modula-3". As long as you do it in Quake, no one will expect things like m3tk to work properly all the time. Once you do it in Modula-3 itself, however, you're inviting users to code absolutely normal modules with preprocessing that really have no need for preprocessing. You can't really say "here's a part of the language we're using that you probably shouldn't use." If it's there, you have to expect programmers to use it. If it's not, if they do weird things in Quake, or generate code in Python, on the other hand, they themselves had better know what they are doing. Mika Jay writes: >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Mika good point, I know that, forgot, thanks for reminding me. > One of the interesting things about Modula-3, or rather anything but C an= >d C++, is easy parsing, easy building of other tools. >=20 >Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the pkg tree? = >You know, they can't understand the source tree without understanding m3mak= >efiles. >=20 >I started a little experiment here. >I added m3-libs/m3core/src/C/common/Cstdio.i3. >This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386. >I'm thinking either: > a) I'm not quite on base and just fork it per-target, as it was > b) provide a little bit of C code with #ifdefs, like making the SEEK_* c= >onstants into VARs and using C to initialize them. That's a bit of a downer= > though, since constants ought to be constants. > c) factor it somehow as I was alluding, like, well, again I'm not sure M= >odula-3 has what I'd want here, but at least for types and constants, you c= >an push the non-portable stuff into Ctargetstdio.i3 and then expose them in= > Cstdio.i3, forking only Ctargetstdio.i. >=20 >I'll explain so I can get my question in. :) >=20 >I understand, say: >=20 >Ctargetstdio.i3 (* one of these per target, with not much content *)=20 >CONST > SEEK_CUR =3D ..; (* target specific probably *)=20 > SEEK_SET =3D ..; ditto=20 > SEEK_END =3D ..; ditto =20 >TYPE > FOO =3D ... ditto =20 >=20 >Cstdio.i3 (* portable *)=20 > CONST > SEEK_CUR =3D Ctargetstdio.SEEK_CUR; > SEEK_SET =3D Ctargetstdio.SEEK_SET; > SEEK_END =3D Ctargetstdio.SEEK_END; >TYPE > FOO =3D Ctargetstdio.FOO; >=20 >FILE =3D UNTRACED REF RECORD END; >=20 > procedure fopen(a: const_char_star; b: const_char_star): FILE; >=20 >It is tedious but I believe it works. >It'd be nice, I think, if every symbol in one interface could be automatica= >lly aliases/exposed in another. > At least for this purpose, maybe not for any other. I'm speculating here,= > so please respond kindly. :) >The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place. >=20 >However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another. >Nevermind for now how you can portably call it. >=20 >Ctargetstdio.i3 (* one of these for every target, but another question in a= > sec ... *) >=20 > PROCEDURE seeksomething(a: off_t); let's say it is int on some pl= >atforms. >=20 >Cstdio.i3 (* the portable one *) >=20 >seeksomething =3D Ctargetstdio.seeksomething; does this work? I should t= >ry it out, read the docs. >=20 >But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int. >It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants. >You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE). >OS_TYPE implies less work, nice. >=20 >Perhaps concatening stuff in arbitrary way with Quake really is the way? >It seems almost sarcastic, but perhaps not. >=20 >As long as the pkg store is easily parsed? >(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..) >=20 >But for that matter --- could be processed by the compiler and = >result in a file with it already accounted for and ship that. Isn't that ju= >st as good? EXCEPT that more thought would have to go into the spec, wherea= >s m3makefile is already a general purpose system that anyone can do anythin= >g with? >=20 >?? >=20 > - Jay > > > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From:= > mika at async.caltech.edu> > > Can you just generate the Modula-3 code you wa= >nt using a Python> script or COBOL or whatever you like instead of trying t= >o foist> preprocessing nastiness on innocent users of high-level Modula-3?>= > > Preprocessing is super nasty. It's not just a question of human> readabi= >lity. m3tk has to be able to read the code, too. I should> be able to write= > a program that reads in (using m3tk) an arbitrary> Modula-3 interface and = >understands it to the point that it can> generate Network Object stubs, int= >er-language call stubs, etc. The> stubs should ALSO be human- and m3tk-read= >able after the transformation!> This should work even if the programmer has= > been very "clever" in> his use of Modula-3 constructs. (Just try getting s= >omething like> that to work with C or C++... it's hopeless once the preproc= >essor> gets involved, and possibly before.)> > Also if I may make a little = >request, if at all possible, please try> not to break binary compatibility = >with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about = >calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--= >_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset= >=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist= > that it depends.> >Putting every platform-specific piece of code in its ow= >n file/directory can=3D> > lead to mass duplication of nearly identical cod= >e.> >Sometimes an #if here or there goes very far in /improving/ code maint= >ainab=3D> >ility.> >A lot of #if here there and everywhere of course can ha= >ve the opposite effe=3D> >ct.> >And I realize if you were to drop support f= >or a target, it is easier to fin=3D> >d/delete files/directories than #ifs,= > but I don't think that's a good enoug=3D> >h reason to sway the decision.>= > >It goes both ways.> >=3D20> >Yes, you could endeavor factor things down s= >o that everything common is in =3D> >common, and everything not-common is i= >n platform-specific. But this is inad=3D> >equate I think. The tail is wagg= >ing the dog unnecessarily I think. If my co=3D> >de very nearly all goes to= >gether, don't make me separate it. Also sometimes=3D> > a different factori= >ng is "encouraged" for other reasons, to match someone =3D> >else's factori= >ng. Look at the C*.i3 files. They actually can be almost all =3D> >be nearl= >y the same, yet they are hardly shared at all. I realize you could =3D> >al= >so do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >=3D> >l the right capabilities for this. Type forwarding, sure. But how abo= >ut pro=3D> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D3D common\ccom= >monstdio.i3 fo=3D> >pen? And having to duplicate a line per type/procedure = >is lame anyway, you =3D> >KIND OF want "module inheritance". However, if yo= >u allow preprocessing base=3D> >d on target, perhaps the need for that goes= > away.> >=3D20> >While extern C varargs functions are generally useless in = >Modula-3, and the=3D> >refore extern __cdecl is fairly rare, it DOES occur = >when you write little h=3D> >elpers in C, such as for errno.> >=3D20> >A go= >od /heuristic/ might be to change the default in any directory that has=3D>= > > no c_source.> >But it is only heuristic.> >=3D20> >Whatever is done here= >, some allowance should probably be made for multiple =3D> >calling convent= >ions in the same file.> >Switching the default to the overwhelming majority= > and then annotating the =3D> >minority is reasonable.> >=3D20> >I still be= >lieve that silently ignoring calling conventions on all but NT386=3D> > is = >VERY reasonable, and that no other platform from here on out will ever =3D>= > >have calling conventions. Esp. not with the same names. When OS/FOO has t= >he=3D> > FOOAPI calling convention, you can just ignore that one on all but= > target =3D> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD p= >ossibly get ug=3D> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();>= > >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >= >The One True Calling Convention for all others, calling convention ignored.= >> >=3D20> >I really believe this is highly highly unlikely to occur, and it= > is not a t=3D> >errible outcome, and this bridge could be crossed in the f= >ar off future.> >The functions that are usually in need of calling conventi= >ons are usually o=3D> >nly present on one system.> >Perhaps ODBC is an extr= >emely rare anomaly and the whole issue is nearly non=3D> >existant.> >That = >could be also.> >A change just for ODBC is probably not the best, though it= > is a very small =3D> >safe harmless change (I always say that :) )> >=3D20= >> >=3D20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.c= >om> From: hosking at cs.purdue.e=3D> >du> Subject: Re: [M3devel] "target speci= >fic pragmas"?> Date: Mon, 11 Feb 20=3D> >08 21:08:46 -0500> To: darko at darko= >.org> > Indeed!> > On Feb 11, 2008, at 8:=3D> >37 PM, Darko wrote:> > > I t= >hink it's not a good idea. I think all platform=3D> > specific code > > sho= >uld be in a separate file. I'd also like to see an op=3D> >tion to > > move= > calling conventions to the makefile rather than in pramas =3D> >to > > avo= >id having to duplicate interface files just to have a different >=3D> > > c= >alling convention for a different platform.> >> > - Darko> >> >> > On 1=3D>= > >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this thro= >ug=3D> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" i= >s a good=3D> > > >> idea.> >>> >> Something like either the ability to pref= >ix pragmas wit=3D> >h a target, > >> or an "iftarget" and "ifnottarget" pra= >gma.> >>> >> Somethi=3D> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* = >END_IF_TARGET*>> >>> >>> >=3D> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGE= >T*>> >> It's a small can of worm=3D> >s.> >> Where can they be placed? Only= > at "global" scope? (ie: toplevel in >=3D> > >> an interface/module).> >>> = >>> What about IF_OSTYPE?> >> What about expr=3D> >essions?> >> IF_TARGET NT= >386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=3D> >> etc.> >>> >> I do= >n't really have enough interest here to work through thi=3D> >s, > >> just = >sending out the bait...> >>> >> Obviously this was triggered b=3D> >y my ha= >ppening into the odbc > >> directory and bringing up ignoring WINAPI=3D> > = >on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >=3D> >This reminds me of an important point here however -- nobody else > >= >> is g=3D> >oing to make the mistake of ever having multiple calling > >> c= >onventions. =3D> >Therefore the generality of prefixing WINAPI with > >> NT= >386: is useless.> =3D> >>> Unless Mac68K support is added.> >>> >> And here= > is some rationale even.=3D> > The PC and Mac evolved from > >> "small" sys= >tems, where assembly programmi=3D> >ng was common, more > >> people knew mo= >re lower level details and playing g=3D> >ames with > >> calling convention= >s was something anyone could do. Most othe=3D> >r > >> current systems are = >rooted in C programming. Working in C, calling >=3D> > >> conventions are g= >enerally in a hidden layer below what anyone > >> thin=3D> >ks about. There= >fore, the smaller number of capable people > >> working at t=3D> >hat level= > have the good sense to only have one calling > >> convention. No =3D> >mor= >e systems will evolve from "small", at least not > >> without having obs=3D= >> >erved this history. Therefore, there will no > >> longer be multiple cal= >lin=3D> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Win= >dows does=3D> > also have __thiscall and __clrcall. __thiscall is > >> only= > x86>=3D20> >______________________________________________________________= >___> >Climb to the top of the charts!=3DA0Play the word scramble challenge = >with sta=3D> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3D3Dst= >arshuffle_wlmailtextlink_ja=3D> >n=3D> >> >--_8b04f633-e2a4-411d-940a-739ab= >79b0616_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Content-Transf= >er-Encoding: quoted-printable> >> >> >> >> >> >e'>I insist that it depends.
> >Putting every platform-specific piece of= > code in its own file/directory can=3D> > lead to mass duplication of nearl= >y identical code.
> >Sometimes an #if here or there goes very far in /im= >proving/ code maintainab=3D> >ility.
> >A lot of #if here there and ever= >ywhere of course can have the opposite effe=3D> >ct.
> >And I realize if= > you were to drop support for a target, it is easier to fin=3D> >d/delete f= >iles/directories than #ifs, but I don't think that's a good enoug=3D> >h re= >ason to sway the decision.
> >It goes both ways.
> > 
> >Yes,= > you could endeavor factor things down so that everything common i=3D>= > >s in common, and everything not-common is in platform-specific. But this = >is=3D> > inadequate I think. The tail is wagging the dog unnecessarily I th= >ink. If =3D> >my code very nearly all goes together, don't make me sep= >arate it. =3D> >;Also sometimes a different factoring is "encouraged" f= >or other reasons, to=3D> > match someone else's factoring. Look at the C*.i= >3 files. They actually can=3D> > be almost all be nearly the same, yet they= > are hardly shared at all. I rea=3D> >lize you could also do a sort of "for= >warding", though I'm not sure that Mod=3D> >ula-3 offers all the right capa= >bilities for this. Type forwarding, sure. Bu=3D> >t how about procedure for= >warding? Like nt386\cstdio.i3 fopen =3D3D common\cco=3D> >mmonstdio.i3 fope= >n? And having to duplicate a line per type/procedure is la=3D> >me anyway, = >you KIND OF want "module inheritance". However, if you allow pre=3D> >proce= >ssing based on target, perhaps the need for that goes away.
> > >> >While extern C varargs functions are generally useless in Modula-3, and= > the=3D> >refore extern __cdecl is fairly rare, it DOES occur when you writ= >e little h=3D> >elpers in C, such as for errno.
> > 
> >A good /= >heuristic/ might be to change the default in any directory that has=3D> > n= >o c_source.
> >But it is only heuristic.
> > 
> >Whatever is = >done here, some allowance should probably be made for multiple =3D> >callin= >g conventions in the same file.
> >Switching the default to the overwhel= >ming majority and then annotating the =3D> >minority is reasonable.
> >&= >nbsp;
> >I still believe that silently ignoring calling conventions on a= >ll but NT386=3D> > is VERY reasonable, and that no other platform from here= > on out will ever =3D> >have calling conventions. Esp. not with the same na= >mes. When OS/FOO has the=3D> > FOOAPI calling convention, you can just igno= >re that one on all but target =3D> >OS/FOO. Just as all but NT386 ignore WI= >NAPI. Yes this COULD possibly get ug=3D> >ly something like:
> ><*EXT= >ERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.>> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention= > for all others, calling convention ignored.=3D> >
> > 
> >I rea= >lly believe this is highly highly unlikely to occur, and it is not a t=3D> = >>errible outcome, and this bridge could be crossed in the far off future.R=3D> >>> >The functions that are usually in need of calling conventions ar= >e usually o=3D> >nly present on one system.
> >Perhaps ODBC is an extrem= >ely rare anomaly and the whole issue is nearly non=3D> >existant.
> >Tha= >t could be also.
> >A change just for ODBC is probably not the best, tho= >ugh it is a very small =3D> >safe harmless change (I always say that :) )R>> > 
> > 
> > - Jay

> >> >
ling>> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> = >From: hosking at c=3D> >s.purdue.edu
> Subject: Re: [M3devel] "target sp= >ecific pragmas"?
&=3D> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
>= >; To: darko at darko.org
&g=3D> >t;
> Indeed!
>
> On Fe= >b 11, 2008, at 8:37 PM, Darko wro=3D> >te:
>
> > I think it= >'s not a good idea. I think all platfor=3D> >m specific code
> > = >should be in a separate file. I'd also like t=3D> >o see an option to
&= >gt; > move calling conventions to the makefile r=3D> >ather than in pram= >as to
> > avoid having to duplicate interface f=3D> >iles just to= > have a different
> > calling convention for a differ=3D> >ent pl= >atform.
> >
> > - Darko
> >
> > >= >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >=3D> >;> So I have NOT thought this through.
> >>
> &g= >t;>=3D> > I wonder if "preprocessing" dependent only on "target" is a go= >od
> =3D> >>> idea.
> >>
> >> Somethin= >g like either the =3D> >ability to prefix pragmas with a target,
> &= >gt;> or an "iftarget"=3D> > and "ifnottarget" pragma.
> >>R>> >> Something like=3D> > so:
> >>
> >> = ><* IF_TARGET NT386 *>
> =3D> >>> <* END_IF_TARGET*>= >
> >>
> >>
>=3D> > >> <* IF_TARGET N= >T386 *>
> >> <* END_IF_TARGET*=3D> >>
> >>= > It's a small can of worms.
> >> Where can=3D> > they be placed= >? Only at "global" scope? (ie: toplevel in
> >>=3D> > an inter= >face/module).
> >>
> >> What about IF_OSTY=3D> >PE?= >
> >> What about expressions?
> >> IF_TARGET NT3=3D= >> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
= >>=3D> >; >>
> >> etc.
> >>
> >>= > I don't =3D> >really have enough interest here to work through this,
&= >gt; >> ju=3D> >st sending out the bait...
> >>
> &g= >t;> Obviously this=3D> > was triggered by my happening into the odbc >> >> directory an=3D> >d bringing up ignoring WINAPI on non-NT386= > or
> >> prefixing c=3D> >alling conventions with a target.>> >>
> >> This re=3D> >minds me of an important point= > here however -- nobody else
> >>=3D> >; is going to make the m= >istake of ever having multiple calling
> >=3D> >;> conventions.= > Therefore the generality of prefixing WINAPI with
&g=3D> >t; >> = >NT386: is useless.
> >> Unless Mac68K support is ad=3D> >ded.R>> >>
> >> And here is some rationale even. The=3D> >= > PC and Mac evolved from
> >> "small" systems, where assembly = >=3D> >programming was common, more
> >> people knew more lower= > level=3D> > details and playing games with
> >> calling conve= >ntions was s=3D> >omething anyone could do. Most other
> >> cu= >rrent systems are =3D> >rooted in C programming. Working in C, calling
= >> >> convention=3D> >s are generally in a hidden layer below what = >anyone
> >> think=3D> >s about. Therefore, the smaller number = >of capable people
> >> =3D> >working at that level have the go= >od sense to only have one calling
>=3D> > >> convention. No mo= >re systems will evolve from "small", at least no=3D> >t
> >> w= >ithout having observed this history. Therefore, there =3D> >will no
>= >; >> longer be multiple calling conventions.
> &=3D> >gt;>R>> >> That is my theory at least.
> >>
&g=3D> >t; = >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall=3D= >> > is
> >> only x86
>


Climb to the = >top=3D> > of the charts!=3DA0Play the word scramble challenge with star pow= >er. >=3D3D'http://club.live.com/star_shuffle.aspx?icid=3D3Dstar= >shuffle_wlmailtextlin=3D> >k_jan' target=3D3D'_new'>Play now!> >= >=3D> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Mika good point, I know that, forgot, thanks for = >reminding me.
>  One of the interesting things about Modula-3, or rather anything but= > C and C++, is easy parsing, easy building of other tools.
> 
>Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the p= >kg tree? You know, they can't understand the source tree without understand= >ing m3makefiles.
> 
>I started a little experiment here.
>I added m3-libs/m3core/src/C/common/Cstdio.i3.
>This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386.
>I'm thinking either:
>   a) I'm not quite on base and just fork it per-target, as it wa= >s
   b) provide a little bit of C code with #ifdefs, like making th= >e SEEK_* constants into VARs and using C to initialize them. That's a bit o= >f a downer though, since constants ought to be constants.
>   c) factor it somehow as I was alluding, like, well, again I'm = >not sure Modula-3 has what I'd want here, but at least for types and consta= >nts, you can push the non-portable stuff into Ctargetstdio.i3 and then expo= >se them in Cstdio.i3, forking only Ctargetstdio.i.
> 
>I'll explain so I can get my question in. :)
> 
>I understand, say:
> 
>Ctargetstdio.i3 (* one of these per target, with not much content *) <= >BR> >CONST
>  SEEK_CUR =3D ..; (* target specific probably *)
>  SEEK_SET =3D ..; ditto
>  SEEK_END =3D ..; ditto 
>TYPE
>  FOO =3D ... ditto 
> 
>Cstdio.i3 (* portable *)
> CONST
>  SEEK_CUR =3D Ctargetstdio.SEEK_CUR;
>  SEEK_SET =3D Ctargetstdio.SEEK_SET;
>  SEEK_END =3D Ctargetstdio.SEEK_END;
>TYPE
>  FOO =3D Ctargetstdio.FOO;
> 
>FILE =3D UNTRACED REF RECORD END;
> 
><extern> procedure fopen(a: const_char_star; b: const_char_star): FIL= >E;
> 
>It is tedious but I believe it works.
>It'd be nice, I think, if every symbol in one interface could be autom= >atically aliases/exposed in another.
>  At least for this purpose, maybe not for any other. I'm speculating = >here, so please respond kindly. :)
>The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place.
> 
>However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another.
>Nevermind for now how you can portably call it.
> 
>Ctargetstdio.i3 (* one of these for every target, but another question in&n= >bsp;a sec ... *)
> 
><extern> PROCEDURE seeksomething(a: off_t);  let's say it is int= > on some platforms.
> 
>Cstdio.i3 (* the portable one *)
> 
>seeksomething =3D Ctargetstdio.seeksomething;    does this w= >ork? I should try it out, read the docs.
> 
>But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int.
>It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants.
>You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE).
>OS_TYPE implies less work, nice.
> 
>Perhaps concatening stuff in arbitrary way with Quake really is the way?> >It seems almost sarcastic, but perhaps not.
> 
>As long as the pkg store is easily parsed?
>(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..)
> 
>But for that matter --- <IF_TARGET> could be processed by the compile= >r and result in a file with it already accounted for and ship that. Isn't t= >hat just as good? EXCEPT that more thought would have to go into the spec, = >whereas m3makefile is already a general purpose system that anyone can do a= >nything with?
> 
>??
> 
> - Jay

> >
>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] "target specific pragmas"?
> Date: Tue, 12 Feb 20= >08 04:56:02 -0800
> From: mika at async.caltech.edu
>
> >> Can you just generate the Modula-3 code you want using a Python
&g= >t; script or COBOL or whatever you like instead of trying to foist
> = >preprocessing nastiness on innocent users of high-level Modula-3?
> <= >BR>> Preprocessing is super nasty. It's not just a question of human
= >> readability. m3tk has to be able to read the code, too. I should
&g= >t; be able to write a program that reads in (using m3tk) an arbitrary
&g= t; Modula-3 interface and understands it to the point that it can
> g= >enerate Network Object stubs, inter-language call stubs, etc. The
> s= >tubs should ALSO be human- and m3tk-readable after the transformation!
&= >gt; This should work even if the programmer has been very "clever" in
&g= >t; his use of Modula-3 constructs. (Just try getting something like
>= > that to work with C or C++... it's hopeless once the preprocessor
> = >gets involved, and possibly before.)
>
> Also if I may make a = >little request, if at all possible, please try
> not to break binary = >compatibility with gcc-compiled C and Fortran
> on NT386GNU (not sure= > if your ideas about calling conventions could
> possibly do that...)= >
>
> Mika
>
> Jay writes:
> >--_8b04f633= >-e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/plain; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> >I insist that it depends.
> >Putting every p= >latform-specific piece of code in its own file/directory can=3D
> >= >; lead to mass duplication of nearly identical code.
> >Sometimes = >an #if here or there goes very far in /improving/ code maintainab=3D
>= >; >ility.
> >A lot of #if here there and everywhere of course c= >an have the opposite effe=3D
> >ct.
> >And I realize if y= >ou were to drop support for a target, it is easier to fin=3D
> >d/= >delete files/directories than #ifs, but I don't think that's a good enoug= >=3D
> >h reason to sway the decision.
> >It goes both way= >s.
> >=3D20
> >Yes, you could endeavor factor things down= > so that everything common is in =3D
> >common, and everything not= >-common is in platform-specific. But this is inad=3D
> >equate I t= >hink. The tail is wagging the dog unnecessarily I think. If my co=3D
>= >; >de very nearly all goes together, don't make me separate it. Also som= >etimes=3D
> > a different factoring is "encouraged" for other reas= >ons, to match someone =3D
> >else's factoring. Look at the C*.i3 f= >iles. They actually can be almost all =3D
> >be nearly the same, y= >et they are hardly shared at all. I realize you could =3D
> >also = >do a sort of "forwarding", though I'm not sure that Modula-3 offers al=3DR>> >l the right capabilities for this. Type forwarding, sure. But ho= >w about pro=3D
> >cedure forwarding? Like nt386\cstdio.i3 fopen = >=3D3D common\ccommonstdio.i3 fo=3D
> >pen? And having to duplicate= > a line per type/procedure is lame anyway, you =3D
> >KIND OF want= > "module inheritance". However, if you allow preprocessing base=3D
> = >>d on target, perhaps the need for that goes away.
> >=3D20
= >> >While extern C varargs functions are generally useless in Modula-3= >, and the=3D
> >refore extern __cdecl is fairly rare, it DOES occu= >r when you write little h=3D
> >elpers in C, such as for errno.>> >=3D20
> >A good /heuristic/ might be to change the defau= >lt in any directory that has=3D
> > no c_source.
> >But i= >t is only heuristic.
> >=3D20
> >Whatever is done here, s= >ome allowance should probably be made for multiple =3D
> >calling = >conventions in the same file.
> >Switching the default to the over= >whelming majority and then annotating the =3D
> >minority is reaso= >nable.
> >=3D20
> >I still believe that silently ignoring= > calling conventions on all but NT386=3D
> > is VERY reasonable, a= >nd that no other platform from here on out will ever =3D
> >have c= >alling conventions. Esp. not with the same names. When OS/FOO has the=3D>> > FOOAPI calling convention, you can just ignore that one on all b= >ut target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes = >this COULD possibly get ug=3D
> >ly something like:
> >&l= >t;*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI= > ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One= > True Calling Convention for all others, calling convention ignored.
>= >; >=3D20
> >I really believe this is highly highly unlikely to = >occur, and it is not a t=3D
> >errible outcome, and this bridge co= >uld be crossed in the far off future.
> >The functions that are us= >ually in need of calling conventions are usually o=3D
> >nly prese= >nt on one system.
> >Perhaps ODBC is an extremely rare anomaly and= > the whole issue is nearly non=3D
> >existant.
> >That co= >uld be also.
> >A change just for ODBC is probably not the best, t= >hough it is a very small =3D
> >safe harmless change (I always say= > that :) )
> >=3D20
> >=3D20
> > - Jay
> &= >gt;
> >
> >
> >> CC: jayk123 at hotmail.com; m3d= >evel at elegosoft.com> From: hosking at cs.purdue.e=3D
> >du> Subj= >ect: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=3DR>> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> &= >gt; On Feb 11, 2008, at 8:=3D
> >37 PM, Darko wrote:> > >= > I think it's not a good idea. I think all platform=3D
> > specifi= >c code > > should be in a separate file. I'd also like to see an op= >=3D
> >tion to > > move calling conventions to the makefile = >rather than in pramas =3D
> >to > > avoid having to duplicat= >e interface files just to have a different >=3D
> > > callin= >g convention for a different platform.> >> > - Darko> >&g= >t; >> > On 1=3D
> >2/02/2008, at 12:21 PM, Jay wrote:>= > >> >> So I have NOT thought this throug=3D
> >h.> = >>>> >> I wonder if "preprocessing" dependent only on "target= >" is a good=3D
> > > >> idea.> >>> >> S= >omething like either the ability to prefix pragmas wit=3D
> >h a t= >arget, > >> or an "iftarget" and "ifnottarget" pragma.> >>= >;> >> Somethi=3D
> >ng like so:> >>> >>= > <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >= >>> >>> >=3D
> >> <* IF_TARGET NT386 *>&= >gt; >> <* END_IF_TARGET*>> >> It's a small can of worm= >=3D
> >s.> >> Where can they be placed? Only at "global" = >scope? (ie: toplevel in >=3D
> > >> an interface/module).= >> >>> >> What about IF_OSTYPE?> >> What about ex= >pr=3D
> >essions?> >> IF_TARGET NT386 OR NTAMD64> >= >>> >> IF_TARGET STARTS(NT)> >>> >=3D
> >= >;> etc.> >>> >> I don't really have enough interest he= >re to work through thi=3D
> >s, > >> just sending out the= > bait...> >>> >> Obviously this was triggered b=3D
>= >; >y my happening into the odbc > >> directory and bringing up = >ignoring WINAPI=3D
> > on non-NT386 or > >> prefixing cal= >ling conventions with a target.> >>> >> =3D
> >T= >his reminds me of an important point here however -- nobody else > >&= >gt; is g=3D
> >oing to make the mistake of ever having multiple ca= >lling > >> conventions. =3D
> >Therefore the generality o= >f prefixing WINAPI with > >> NT386: is useless.> =3D
> &g= >t;>> Unless Mac68K support is added.> >>> >> And he= >re is some rationale even.=3D
> > The PC and Mac evolved from >= > >> "small" systems, where assembly programmi=3D
> >ng was c= >ommon, more > >> people knew more lower level details and playing = >g=3D
> >ames with > >> calling conventions was something = >anyone could do. Most othe=3D
> >r > >> current systems a= >re rooted in C programming. Working in C, calling >=3D
> > >= >> conventions are generally in a hidden layer below what anyone > >= >;> thin=3D
> >ks about. Therefore, the smaller number of capabl= >e people > >> working at t=3D
> >hat level have the good = >sense to only have one calling > >> convention. No =3D
> >= >;more systems will evolve from "small", at least not > >> without = >having obs=3D
> >erved this history. Therefore, there will no >= > >> longer be multiple callin=3D
> >g conventions.> >&= >gt;> >> That is my theory at least.> >>> >> Oh, = >Windows does=3D
> > also have __thiscall and __clrcall. __thiscall= > is > >> only x86>=3D20
> >___________________________= >______________________________________
> >Climb to the top of the = >charts!=3DA0Play the word scramble challenge with sta=3D
> >r powe= >r.
> >http://club.live.com/star_shuffle.aspx?icid=3D3Dstarshuffle_= >wlmailtextlink_ja=3D
> >n=3D
> >
> >--_8b04f633-= >e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/html; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> ><html>
> ><head>
> ><= >;style>
> >.hmmessage P
> >{
> >margin:0px;R>> >padding:0px
> >}
> >body.hmmessage
> >= >;{
> >FONT-SIZE: 10pt;
> >FONT-FAMILY:Tahoma
> >= >}
> ></style>
> ></head>
> ><body= > class=3D3D'hmmessage'>I insist that it depends.<BR>
> >P= >utting every platform-specific piece of code in its own file/directory can= >=3D
> > lead to mass duplication of nearly identical code.<BR&g= >t;
> >Sometimes an #if here or there goes very far in /improving/ = >code maintainab=3D
> >ility.<BR>
> >A lot of #if he= >re there and everywhere of course can have the opposite effe=3D
> >= >;ct.<BR>
> >And I realize if you were to drop support for a = >target, it is easier to fin=3D
> >d/delete files/directories than = >#ifs, but I don't think that's a good enoug=3D
> >h reason to sway= > the decision.<BR>
> >It goes both ways.<BR>
> &= >gt;&nbsp;<BR>
> >Yes, you could endeavor&nbsp;factor= > things down so that everything common i=3D
> >s in common, and ev= >erything not-common is in platform-specific. But this is=3D
> > in= >adequate I think. The tail is wagging the dog unnecessarily I think. If =3D= >
> >my code very nearly all goes together, don't make me&nbsp;= >separate it.&nbsp=3D
> >;Also sometimes a different factoring = >is "encouraged" for other reasons, to=3D
> > match someone else's = >factoring. Look at the C*.i3 files. They actually can=3D
> > be al= >most all be nearly the same, yet they are hardly shared at all. I rea=3D>> >lize you could also do a sort of "forwarding", though I'm not sur= >e that Mod=3D
> >ula-3 offers all the right capabilities for this.= > Type forwarding, sure. Bu=3D
> >t how about procedure forwarding?= > Like nt386\cstdio.i3 fopen =3D3D common\cco=3D
> >mmonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is la=3D
> >= >;me anyway, you KIND OF want "module inheritance". However, if you allow pr= >e=3D
> >processing based on target, perhaps the need for that goes= > away.<BR>
> >&nbsp;<BR>
> >While extern = >C varargs functions are generally useless in Modula-3, and the=3D
> &= >gt;refore extern __cdecl is fairly rare, it DOES occur when you write littl= >e h=3D
> >elpers in C, such as for errno.<BR>
> >&a= >mp;nbsp;<BR>
> >A good /heuristic/ might be to change the de= >fault in any directory that has=3D
> > no c_source.<BR>
&= >gt; >But it is only heuristic.<BR>
> >&nbsp;<BR>= >;
> >Whatever is done here, some allowance should probably be made= > for multiple =3D
> >calling conventions in the same file.<BR&g= >t;
> >Switching the default to the overwhelming majority and then = >annotating the =3D
> >minority is reasonable.<BR>
> &g= >t;&nbsp;<BR>
> >I still believe that silently ignoring c= >alling conventions on all but NT386=3D
> > is VERY reasonable, and= > that no other platform from here on out will ever =3D
> >have cal= >ling conventions. Esp. not with the same names. When OS/FOO has the=3D
&= >gt; > FOOAPI calling convention, you can just ignore that one on all but= > target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes th= is COULD possibly get ug=3D
> >ly something like:<BR>
>= >; >&lt;*EXTERN FOOAPI WINAPI*&gt; fopen();<BR>
> >= >;FOOAPI for OS/FOO, WINAPI ignored.<BR>
> >WINAPI for NT386,= > FOOAPI ignored.<BR>
> >The One True Calling Convention for = >all others, calling convention ignored.=3D
> ><BR>
> &= >gt;&nbsp;<BR>
> >I really believe this is highly highly = >unlikely to occur, and it is not a t=3D
> >errible outcome, and th= >is bridge could be crossed in the far off future.<BR=3D
> >>= >
> >The functions that are usually in need of calling conventions = >are usually o=3D
> >nly present on one system.<BR>
> &= >gt;Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly = >non=3D
> >existant.<BR>
> >That could be also.<B= >R>
> >A change just for ODBC is probably not the best, though i= >t is a very small =3D
> >safe harmless change (I always say that := >) )<BR>
> >&nbsp;<BR>
> >&nbsp;<BR= >>
> >&nbsp;- Jay<BR><BR>
> >
> &= >gt;<HR id=3D3DstopSpelling>
> ><BR>
> >&g= >t; CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>&gt; From: h= >osking at c=3D
> >s.purdue.edu<BR>&gt; Subject: Re: [M3deve= >l] "target specific pragmas"?<BR>&=3D
> >gt; Date: Mon, = >11 Feb 2008 21:08:46 -0500<BR>&gt; To: darko at darko.org<BR>&= >amp;g=3D
> >t; <BR>&gt; Indeed!<BR>&gt; <BR= >>&gt; On Feb 11, 2008, at 8:37 PM, Darko wro=3D
> >te:<B= >R>&gt; <BR>&gt; &gt; I think it's not a good idea. I t= >hink all platfor=3D
> >m specific code <BR>&gt; &gt;= > should be in a separate file. I'd also like t=3D
> >o see an opti= >on to <BR>&gt; &gt; move calling conventions to the makefile = >r=3D
> >ather than in pramas to <BR>&gt; &gt; avoid = >having to duplicate interface f=3D
> >iles just to have a differen= >t <BR>&gt; &gt; calling convention for a differ=3D
> &g= >t;ent platform.<BR>&gt; &gt;<BR>&gt; &gt; - Dar= >ko<BR>&gt; &gt;<BR>&gt; &gt;<B=3D
> &g= >t;R>&gt; &gt; On 12/02/2008, at 12:21 PM, Jay wrote:<BR>&a= >mp;gt; &gt;<BR>&gt; &gt=3D
> >;&gt; So I hav= >e NOT thought this through.<BR>&gt; &gt;&gt;<BR>&am= >p;gt; &gt;&gt;=3D
> > I wonder if "preprocessing" dependen= >t only on "target" is a good <BR>&gt; =3D
> >&gt;&am= >p;gt; idea.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&a= >mp;gt; Something like either the =3D
> >ability to prefix pragmas = >with a target, <BR>&gt; &gt;&gt; or an "iftarget"=3D
&= >gt; > and "ifnottarget" pragma.<BR>&gt; &gt;&gt;<BR= >>&gt; &gt;&gt; Something like=3D
> > so:<BR>&= >amp;gt; &gt;&gt;<BR>&gt; &gt;&gt; &lt;* IF_TA= >RGET NT386 *&gt;<BR>&gt; =3D
> >&gt;&gt; &am= >p;lt;* END_IF_TARGET*&gt;<BR>&gt; &gt;&gt;<BR>&= >amp;gt; &gt;&gt;<BR>&gt;=3D
> > &gt;&gt;= > &lt;* IF_TARGET NT386 *&gt;<BR>&gt; &gt;&gt; &am= >p;lt;* END_IF_TARGET*=3D
> >&gt;<BR>&gt; &gt;&am= >p;gt; It's a small can of worms.<BR>&gt; &gt;&gt; Where c= >an=3D
> > they be placed? Only at "global" scope? (ie: toplevel in= > <BR>&gt; &gt;&gt;=3D
> > an interface/module).&= >lt;BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; What = >about IF_OSTY=3D
> >PE?<BR>&gt; &gt;&gt; What ab= >out expressions?<BR>&gt; &gt;&gt; IF_TARGET NT3=3D
>= >; >86 OR NTAMD64<BR>&gt; &gt;&gt;<BR>&gt; &a= >mp;gt;&gt; IF_TARGET STARTS(NT)<BR>&gt=3D
> >; &= >gt;&gt;<BR>&gt; &gt;&gt; etc.<BR>&gt; &= >gt;&gt;<BR>&gt; &gt;&gt; I don't =3D
> >real= >ly have enough interest here to work through this, <BR>&gt; &= >gt;&gt; ju=3D
> >st sending out the bait...<BR>&gt; = >&gt;&gt;<BR>&gt; &gt;&gt; Obviously this=3D
&g= >t; > was triggered by my happening into the odbc <BR>&gt; &= >;gt;&gt; directory an=3D
> >d bringing up ignoring WINAPI on n= >on-NT386 or <BR>&gt; &gt;&gt; prefixing c=3D
> >= >alling conventions with a target.<BR>&gt; &gt;&gt;<BR&= >gt;&gt; &gt;&gt; This re=3D
> >minds me of an importan= >t point here however -- nobody else <BR>&gt; &gt;&gt=3DR>> >; is going to make the mistake of ever having multiple calling &= >lt;BR>&gt; &gt=3D
> >;&gt; conventions. Therefore t= >he generality of prefixing WINAPI with <BR>&g=3D
> >t; &= >amp;gt;&gt; NT386: is useless.<BR>&gt; &gt;&gt; Unles= >s Mac68K support is ad=3D
> >ded.<BR>&gt; &gt;&g= >t;<BR>&gt; &gt;&gt; And here is some rationale even. The= >=3D
> > PC and Mac evolved from <BR>&gt; &gt;&gt= >; "small" systems, where assembly =3D
> >programming was common, m= >ore <BR>&gt; &gt;&gt; people knew more lower level=3D
= >> > details and playing games with <BR>&gt; &gt;&gt= >; calling conventions was s=3D
> >omething anyone could do. Most o= >ther <BR>&gt; &gt;&gt; current systems are =3D
> &g= >t;rooted in C programming. Working in C, calling <BR>&gt; &gt= >;&gt; convention=3D
> >s are generally in a hidden layer below= > what anyone <BR>&gt; &gt;&gt; think=3D
> >s abo= >ut. Therefore, the smaller number of capable people <BR>&gt; &= >;gt;&gt; =3D
> >working at that level have the good sense to o= >nly have one calling <BR>&gt;=3D
> > &gt;&gt; co= >nvention. No more systems will evolve from "small", at least no=3D
> = >>t <BR>&gt; &gt;&gt; without having observed this hist= >ory. Therefore, there =3D
> >will no <BR>&gt; &gt;&a= >mp;gt; longer be multiple calling conventions.<BR>&gt; &=3DR>> >gt;&gt;<BR>&gt; &gt;&gt; That is my theory= > at least.<BR>&gt; &gt;&gt;<BR>&g=3D
> &g= >t;t; &gt;&gt; Oh, Windows does also have __thiscall and __clrcall. = >__thiscall=3D
> > is <BR>&gt; &gt;&gt; only x86&= >lt;BR>&gt; <BR><BR><br /><hr />Climb to the = >top=3D
> > of the charts!=3DA0Play the word scramble challenge wit= >h star power. <a href=3D
> >=3D3D'http://club.live.com/star_shu= >ffle.aspx?icid=3D3Dstarshuffle_wlmailtextlin=3D
> >k_jan' target= >=3D3D'_new'>Play now!</a></body>
> ></html>= >=3D
> >
> >--_8b04f633-e2a4-411d-940a-739ab79b0616_--
= >

Climb to the top of the charts!=A0Play the word scramble ch= >allenge with star power. icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now! >= > >--_91974b83-e297-4ab9-ba44-e888f600b934_-- From mika at async.caltech.edu Tue Feb 12 22:27:15 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:27:15 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 14:02:23 GMT." Message-ID: <200802122127.m1CLRFi0007370@camembert.async.caltech.edu> Jay writes: >Mika your switch example, besides being invalid C++, is just not fair. >I don't think people even think to write their code like that. >Introducing variables at the top of a switch is rare, esp. initializing the= >m. The example didn't come out of nowhere. I once, a very long time ago, being a not completely competent C programmer, wrote a program like that and spent quite a while debugging it before I realized that the initializations weren't being called. I think I was thinking that initializations are like Fortran DATA statements, or at least should be, in any civilized programming language. If you're extending the stack frame to make room for the declared variables, shouldn't you be calling the initialization code, too? Apparently not... Another way of looking at it is that it was just one of those bizarre little bugs that led me to program in Modula-3. Actually, I remember what finally drove me over the edge. I had written a program to make plots of large VLSI chips at very high resolution (300+ megapixel) using alpha blending, etc., and it was working wonderfully (for years) on FreeBSD. I tried to port it to Linux (trivial, right?) and discovered that I couldn't write a bug-free generic linked list library in C to save my life. The data structures in the program were a bit tricky because of the size of the database, and the fact that I wanted to run it in a small amount of memory. In those days the custom was you had one server with a large amount of RAM (1GB) and a bunch of workstations with 64 or 128 MB. My goal was to run the program, which could take up to a week each time, on the workstations rather than tying up the server (which was busy with other stuff). After I had finally debugged the last memory problem with my program, I sat down and wrote a bug-free one in about two days in Modula-3, a programming language that I previously just vaguely knew as a "fancier Pascal". Mika From dragisha at m3w.org Tue Feb 12 22:24:55 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:24:55 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: <1202851495.3771.3.camel@faramir.m3w.org> This is new project... and it's pretty drafty, meaning it compiles but it does not run. I sumbitted this because it looks like some obscure (underreported?) error to me. Compiler I do use is pretty stable and build lots of my other apps. On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: > Did something change in m3middle/m3front lately? > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > > > % cm3 > > --- building in ../LINUXLIBC6 --- > > > > new source -> compiling Connection.i3 > > new source -> compiling Connection.m3 > > new source -> compiling PDU.i3 > > new source -> compiling PDU.m3 > > "../src/PDU.m3", line 107: warning: not used (len) > > "../src/PDU.m3", line 104: warning: not used (b) > > "../src/PDU.m3", line 116: warning: open array passed by value (o) > > "../src/PDU.m3", line 118: warning: not used (cStr) > > "../src/PDU.m3", line 116: warning: not used (b) > > "../src/PDU.m3", line 116: warning: not used (o) > > "../src/PDU.m3", line 160: warning: not used (c) > > "../src/PDU.m3", line 59: warning: not used (GetInt) > > 8 warnings encountered > > new source -> compiling SMPP.m3 > > "../src/SMPP.m3", line 1: 4 code generation errors > > 1 error encountered > > compilation failed => not building program "smpp" > > Fatal Error: package build failed > > > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From wagner at elegosoft.com Tue Feb 12 23:17:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:17:22 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Message-ID: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Quoting Olaf Wagner : > the builds I started again this morning before leaving home seem to > have succeeded again. I don't understand why compilation with the > latest sources on my own system was broken though; I'll have to > check that tonight. Just one more short followup on this. When I got home, I updated to the latest sources again and ran do-cm3-core.sh. Again, everything compiled, but the executable crashed immediately. I then removed all derived files (realclean) and built again, and this time it worked. So the changes made within the last two days must have touched a subtle dependency of compiler and runtime that the builder does not know or detect. I'd like to understand it better, but it is probably too much effort to isolate all the changes and test them one by one. Sometimes it's just easier to use realclean :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 12 23:22:45 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:22:45 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Quoting Dragi?a Duri? : > This is new project... and it's pretty drafty, meaning it compiles but > it does not run. I sumbitted this because it looks like some obscure > (underreported?) error to me. > > Compiler I do use is pretty stable and build lots of my other apps. > > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >> Did something change in m3middle/m3front lately? >> >> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >> >> > % cm3 >> > --- building in ../LINUXLIBC6 --- [...] >> > "../src/SMPP.m3", line 1: 4 code generation errors >> > 1 error encountered If you could try and post a minimal example that provokes this failure, I'm sure someone on this list can help to solve the problem. Just the lines above provide too little information though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Feb 12 22:35:12 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:35:12 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B1B848.1E75.00D7.1@scires.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> Message-ID: <1202852112.3771.13.camel@faramir.m3w.org> What we _maybe_ can do... is to make some special, preprocessable source form, which some quake command can parse into multiple files in their folders. And these file can be compiled later...Kind of how generic works. But, as current system works, and it does it very well, and as only case where we really need this is Windows... most Unices being or becoming POSIX... I don't see it's smart to spend resources on becoming more C... Esp when "founding fathers" made it so good and so much non-C :). If we really need to make some approach to "their world", it's much better to work on interoperability issues and thus cement our first-class-citizen language status even more. dd On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > Jay: > > My understanding of Modula-3 is that rather than cluttering up the > source code with a bunch of preprocessor directives to deal with the > various changes needed by various platforms, a separate source file is > used for platforms whose implementation must diverge. The m3makefile > is used to control the selection of these platform sources at build > time. I like this approach much better. > > Regards, > Randy > > >>> Jay 2/11/2008 8:21 PM >>> > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, or > an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in an > interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling conventions. > Therefore the generality of prefixing WINAPI with NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew more > lower level details and playing games with calling conventions was > something anyone could do. Most other current systems are rooted in C > programming. Working in C, calling conventions are generally in a > hidden layer below what anyone thinks about. Therefore, the smaller > number of capable people working at that level have the good sense to > only have one calling convention. No more systems will evolve from > "small", at least not without having observed this history. Therefore, > there will no longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 -- Dragi?a Duri? From jayk123 at hotmail.com Tue Feb 12 23:23:30 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:23:30 +0000 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: >From reading the code easily/quickly, this is strange. > > > "../src/SMPP.m3", line 1: 4 code generation errors should be preceded by other sorts of errors. And they all/almost all sound "like internal errors", like assertion failures in m3middle. In particular one of: m3-sys\m3middle\src\M3CG_Check.m3(190):PROCEDURE PutErr (u: U; a, b, c: TEXT := NIL) =m3-sys\m3middle\src\M3CG_Check.m3(194): END PutErr;m3-sys\m3middle\src\M3CG_Check.m3(242): PutErr (self, "bad stack: expected [ ",m3-sys\m3middle\src\M3CG_Check.m3(261): ELSE PutErr (self, "stack overflow");m3-sys\m3middle\src\M3CG_Check.m3(274): PutErr (self, "non-empty stack: ", Stack_Dump (self));m3-sys\m3middle\src\M3CG_Check.m3(382): PutErr (self, "redefined runtime proc: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(391): PutErr (self, "redefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(400): PutErr (self, "undefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(410): PutErr (self, "NIL variable");m3-sys\m3middle\src\M3CG_Check.m3(432): PutErr (self, "temporary reused while live!");m3-sys\m3middle\src\M3CG_Check.m3(446): PutErr (self, "temp freed twice");m3-sys\m3middle\src\M3CG_Check.m3(458): PutErr (self, "nested static initialization");m3-sys\m3middle\src\M3CG_Check.m3(470): ELSE PutErr (self, "missing begin_init");m3-sys\m3middle\src\M3CG_Check.m3(477): IF (self.in_init <= 0) THEN PutErr (self, "missing begin_init") END;m3-sys\m3middle\src\M3CG_Check.m3(480): ELSE PutErr (self, "decreasing offsets");m3-sys\m3middle\src\M3CG_Check.m3(532): PutErr (self, "NIL procedure");m3-sys\m3middle\src\M3CG_Check.m3(540): PutErr (self, "nested procedure declaration");m3-sys\m3middle\src\M3CG_Check.m3(551): ELSE PutErr (self, "missing begin_procedure");m3-sys\m3middle\src\M3CG_Check.m3(554): PutErr (self, "missing end_blocks: ", Int (self.block_count));m3-sys\m3middle\src\M3CG_Check.m3(562): PutErr (self, "temp not freed, created on line ", Int (line));m3-sys\m3middle\src\M3CG_Check.m3(574): PutErr (self, "begin_block not in procedure");m3-sys\m3middle\src\M3CG_Check.m3(586): ELSE PutErr (self, "missing begin_block");m3-sys\m3middle\src\M3CG_Check.m3(604): PutErr (self, "undefined label: ", Int (l));m3-sys\m3middle\src\M3CG_Check.m3(716): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(724): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(739): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(747): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(775): PutErr (self, "floating-point literal doesn't match type");m3-sys\m3middle\src\M3CG_Check.m3(1231): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1242): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1251): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1260): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1268): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1279): ELSE PutErr (self, "missing start_call");34 occurrence(s) have been found. - Jay > From: dragisha at m3w.org> To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 22:24:55 +0100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] wtf "code generation errors"?> > This is new project... and it's pretty drafty, meaning it compiles but> it does not run. I sumbitted this because it looks like some obscure> (underreported?) error to me.> > Compiler I do use is pretty stable and build lots of my other apps.> > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote:> > Did something change in m3middle/m3front lately?> > > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote:> > > > > % cm3> > > --- building in ../LINUXLIBC6 ---> > >> > > new source -> compiling Connection.i3> > > new source -> compiling Connection.m3> > > new source -> compiling PDU.i3> > > new source -> compiling PDU.m3> > > "../src/PDU.m3", line 107: warning: not used (len)> > > "../src/PDU.m3", line 104: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: open array passed by value (o)> > > "../src/PDU.m3", line 118: warning: not used (cStr)> > > "../src/PDU.m3", line 116: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: not used (o)> > > "../src/PDU.m3", line 160: warning: not used (c)> > > "../src/PDU.m3", line 59: warning: not used (GetInt)> > > 8 warnings encountered> > > new source -> compiling SMPP.m3> > > "../src/SMPP.m3", line 1: 4 code generation errors> > > 1 error encountered> > > compilation failed => not building program "smpp"> > > Fatal Error: package build failed> > >> > > -- > > > Dragi?a Duri? > > > -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:26:57 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:26:57 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some. Does it happen on birch? Or only FreeBSD? I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this. Ideally it happens on birch, much quicker for me to get into. Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:30:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:30:23 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: I'm still left wondering -- these other language tools -- you run them over the pkg store's shipped implementation files, right? Or at least check the BUILD_DIR for derived *3 files? Or do the tools, like, ignore missing implementations or other "small" problems? If the "forwarding" shown works, that goes very far in solving this problem without stepping on other language tools (again though, depending somewhat on the first question -- except, I just remembered -- a lot of these tools only need the *.i3 files and not the *.m3 files?) - Jay > Subject: Re: [M3devel] "target specific pragmas"?> From: dragisha at m3w.org> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> Date: Tue, 12 Feb 2008 22:35:12 +0100> > What we _maybe_ can do... is to make some special, preprocessable source> form, which some quake command can parse into multiple files in their> folders. And these file can be compiled later...Kind of how generic> works. > > But, as current system works, and it does it very well, and as only case> where we really need this is Windows... most Unices being or becoming> POSIX... I don't see it's smart to spend resources on becoming more C...> Esp when "founding fathers" made it so good and so much non-C :).> > If we really need to make some approach to "their world", it's much> better to work on interoperability issues and thus cement our> first-class-citizen language status even more.> > dd> > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > Jay:> > > > My understanding of Modula-3 is that rather than cluttering up the> > source code with a bunch of preprocessor directives to deal with the> > various changes needed by various platforms, a separate source file is> > used for platforms whose implementation must diverge. The m3makefile> > is used to control the selection of these platform sources at build> > time. I like this approach much better.> > > > Regards,> > Randy> > > > >>> Jay 2/11/2008 8:21 PM >>>> > So I have NOT thought this through.> > > > I wonder if "preprocessing" dependent only on "target" is a good idea.> > > > Something like either the ability to prefix pragmas with a target, or> > an "iftarget" and "ifnottarget" pragma.> > > > Something like so:> > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > > > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > It's a small can of worms.> > Where can they be placed? Only at "global" scope? (ie: toplevel in an> > interface/module).> > > > What about IF_OSTYPE?> > What about expressions?> > IF_TARGET NT386 OR NTAMD64> > > > IF_TARGET STARTS(NT)> > > > etc.> > > > I don't really have enough interest here to work through this, just> > sending out the bait...> > > > Obviously this was triggered by my happening into the odbc directory> > and bringing up ignoring WINAPI on non-NT386 or prefixing calling> > conventions with a target.> > > > This reminds me of an important point here however -- nobody else is> > going to make the mistake of ever having multiple calling conventions.> > Therefore the generality of prefixing WINAPI with NT386: is useless.> > Unless Mac68K support is added.> > > > And here is some rationale even. The PC and Mac evolved from "small"> > systems, where assembly programming was common, more people knew more> > lower level details and playing games with calling conventions was> > something anyone could do. Most other current systems are rooted in C> > programming. Working in C, calling conventions are generally in a> > hidden layer below what anyone thinks about. Therefore, the smaller> > number of capable people working at that level have the good sense to> > only have one calling convention. No more systems will evolve from> > "small", at least not without having observed this history. Therefore,> > there will no longer be multiple calling conventions.> > > > That is my theory at least.> > > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is> > only x86> -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:33:34 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:33:34 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Olaf, Oh, upon closer read, things are ok now? This could still be somehow attributed to my "VAL" change? And once realclean once, build repeatedly, and it never comes back? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 22:26:57 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some.Does it happen on birch? Or only FreeBSD?I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this.Ideally it happens on birch, much quicker for me to get into.Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 23:52:21 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:52:21 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <20080212235221.3l9sf3f9c088gw04@mail.elegosoft.com> Quoting Jay : > Olaf, Oh, upon closer read, things are ok now? This could still be > somehow attributed to my "VAL" change? > And once realclean once, build repeatedly, and it never comes back? It's all ok now, though we have introduced some incompatibility somewhere, and the builder can't find it. It shows up in other errors when trying to build the whole set of packages, for example: === package m3-ui/mgkit === +++ cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ --- building in FreeBSD4 --- Fatal Error: bad version stamps: PlttFrnds.i3 inconsistent opaque object info for type _t1541f475 super type: _te422a136 data: (size: 32, align: 32) method: (size: 0) => PlttFrnds.i3 super type: _te422a136 data: (size: 64, align: 32) method: (size: 0) => RectsVBT.i3 *** execution of cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' failed *** Ideally, such things shouldn't happen with M3, but I'm pretty sure the package will compile from scratch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 00:54:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:54:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: My principle concern is that once we provide C APIs then C will permeate the M3 space more pervasively (both apps and libraries). What happens when I want to bring up a system where there is no C?!?! Consider the SPIN OS perhaps... Maybe I am just being overly fusty... On Feb 12, 2008, at 4:35 PM, Dragi?a Duri? wrote: > What we _maybe_ can do... is to make some special, preprocessable > source > form, which some quake command can parse into multiple files in their > folders. And these file can be compiled later...Kind of how generic > works. > > But, as current system works, and it does it very well, and as only > case > where we really need this is Windows... most Unices being or becoming > POSIX... I don't see it's smart to spend resources on becoming more > C... > Esp when "founding fathers" made it so good and so much non-C :). > > If we really need to make some approach to "their world", it's much > better to work on interoperability issues and thus cement our > first-class-citizen language status even more. > > dd > > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >> Jay: >> >> My understanding of Modula-3 is that rather than cluttering up the >> source code with a bunch of preprocessor directives to deal with the >> various changes needed by various platforms, a separate source >> file is >> used for platforms whose implementation must diverge. The m3makefile >> is used to control the selection of these platform sources at build >> time. I like this approach much better. >> >> Regards, >> Randy >> >>>>> Jay 2/11/2008 8:21 PM >>> >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, or >> an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in an >> interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, just >> sending out the bait... >> >> Obviously this was triggered by my happening into the odbc directory >> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >> conventions with a target. >> >> This reminds me of an important point here however -- nobody else is >> going to make the mistake of ever having multiple calling >> conventions. >> Therefore the generality of prefixing WINAPI with NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from "small" >> systems, where assembly programming was common, more people knew more >> lower level details and playing games with calling conventions was >> something anyone could do. Most other current systems are rooted in C >> programming. Working in C, calling conventions are generally in a >> hidden layer below what anyone thinks about. Therefore, the smaller >> number of capable people working at that level have the good sense to >> only have one calling convention. No more systems will evolve from >> "small", at least not without having observed this history. >> Therefore, >> there will no longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Feb 13 00:56:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:56:31 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Message-ID: <15AF5E94-4440-450A-BFC4-9553CEB25A03@cs.purdue.edu> Certainly, anything provoking an m3middle error of this kind needs fixing. Can we see a code fragment (and preferably a compilable test case) that generates this error? On Feb 12, 2008, at 5:22 PM, Olaf Wagner wrote: > Quoting Dragi?a Duri? : >> This is new project... and it's pretty drafty, meaning it compiles >> but >> it does not run. I sumbitted this because it looks like some obscure >> (underreported?) error to me. >> >> Compiler I do use is pretty stable and build lots of my other apps. >> >> On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >>> Did something change in m3middle/m3front lately? >>> >>> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >>> >>> > % cm3 >>> > --- building in ../LINUXLIBC6 --- > [...] >>> > "../src/SMPP.m3", line 1: 4 code generation errors >>> > 1 error encountered > > If you could try and post a minimal example that provokes this > failure, I'm sure someone on this list can help to solve the problem. > Just the lines above provide too little information though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Wed Feb 13 00:57:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:57:19 -0500 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <562DD220-6570-4F79-85D9-85F74092A9F9@cs.purdue.edu> I am betting the change to MUTEX definition broke depedent code. On Feb 12, 2008, at 5:17 PM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> the builds I started again this morning before leaving home seem to >> have succeeded again. I don't understand why compilation with the >> latest sources on my own system was broken though; I'll have to >> check that tonight. > > Just one more short followup on this. When I got home, I updated > to the latest sources again and ran do-cm3-core.sh. Again, everything > compiled, but the executable crashed immediately. I then removed > all derived files (realclean) and built again, and this time it > worked. So the changes made within the last two days must have > touched a subtle dependency of compiler and runtime that the builder > does not know or detect. I'd like to understand it better, but it is > probably too much effort to isolate all the changes and test them > one by one. Sometimes it's just easier to use realclean :-/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 01:37:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 16:37:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 18:54:50 EST." Message-ID: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> This is also an excellent reason not to permit "interfaces" to C code inlined into MODULEs. Interfaces are the contract that the implementation has to live up to. Ok, so it happens that under operating system X on architecture Y, the easiest way to implement the interface is to call a C function that "just happens" to have the correct interface. But on another system, which either isn't built in C or where the function doesn't exist, it might be convenient to implement the interface in (gasp!) Modula-3! (I use this pattern as follows: on systems where Intel's Fortran compiler is available, compile from assembly (which was generated by ifort). On other systems, the code is implemented in Modula-3.) Mika Tony Hosking writes: >My principle concern is that once we provide C APIs then C will >permeate the M3 space more pervasively (both apps and libraries). >What happens when I want to bring up a system where there is no >C?!?! Consider the SPIN OS perhaps... > >Maybe I am just being overly fusty... > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > >> What we _maybe_ can do... is to make some special, preprocessable >> source >> form, which some quake command can parse into multiple files in their >> folders. And these file can be compiled later...Kind of how generic >> works. >> >> But, as current system works, and it does it very well, and as only >> case >> where we really need this is Windows... most Unices being or becoming >> POSIX... I don't see it's smart to spend resources on becoming more >> C... >> Esp when "founding fathers" made it so good and so much non-C :). >> >> If we really need to make some approach to "their world", it's much >> better to work on interoperability issues and thus cement our >> first-class-citizen language status even more. >> >> dd >> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >>> Jay: >>> >>> My understanding of Modula-3 is that rather than cluttering up the >>> source code with a bunch of preprocessor directives to deal with the >>> various changes needed by various platforms, a separate source >>> file is >>> used for platforms whose implementation must diverge. The m3makefile >>> is used to control the selection of these platform sources at build >>> time. I like this approach much better. >>> >>> Regards, >>> Randy >>> >>>>>> Jay 2/11/2008 8:21 PM >>> >>> So I have NOT thought this through. >>> >>> I wonder if "preprocessing" dependent only on "target" is a good >>> idea. >>> >>> Something like either the ability to prefix pragmas with a target, or >>> an "iftarget" and "ifnottarget" pragma. >>> >>> Something like so: >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> It's a small can of worms. >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an >>> interface/module). >>> >>> What about IF_OSTYPE? >>> What about expressions? >>> IF_TARGET NT386 OR NTAMD64 >>> >>> IF_TARGET STARTS(NT) >>> >>> etc. >>> >>> I don't really have enough interest here to work through this, just >>> sending out the bait... >>> >>> Obviously this was triggered by my happening into the odbc directory >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >>> conventions with a target. >>> >>> This reminds me of an important point here however -- nobody else is >>> going to make the mistake of ever having multiple calling >>> conventions. >>> Therefore the generality of prefixing WINAPI with NT386: is useless. >>> Unless Mac68K support is added. >>> >>> And here is some rationale even. The PC and Mac evolved from "small" >>> systems, where assembly programming was common, more people knew more >>> lower level details and playing games with calling conventions was >>> something anyone could do. Most other current systems are rooted in C >>> programming. Working in C, calling conventions are generally in a >>> hidden layer below what anyone thinks about. Therefore, the smaller >>> number of capable people working at that level have the good sense to >>> only have one calling convention. No more systems will evolve from >>> "small", at least not without having observed this history. >>> Therefore, >>> there will no longer be multiple calling conventions. >>> >>> That is my theory at least. >>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >>> only x86 >> -- >> Dragi??a Duri?? From jayk123 at hotmail.com Wed Feb 13 05:28:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 04:28:41 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix?There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 16:37:43 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > > This is also an excellent reason not to permit "interfaces" to C> code inlined into MODULEs.> > Interfaces are the contract that the implementation has to live up> to. Ok, so it happens that under operating system X on architecture> Y, the easiest way to implement the interface is to call a C function> that "just happens" to have the correct interface. But on another> system, which either isn't built in C or where the function doesn't> exist, it might be convenient to implement the interface in (gasp!)> Modula-3!> > (I use this pattern as follows: on systems where Intel's Fortran> compiler is available, compile from assembly (which was generated> by ifort). On other systems, the code is implemented in Modula-3.)> > Mika> > Tony Hosking writes:> >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps...> >> >Maybe I am just being overly fusty...> >> >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> >> >> What we _maybe_ can do... is to make some special, preprocessable > >> source> >> form, which some quake command can parse into multiple files in their> >> folders. And these file can be compiled later...Kind of how generic> >> works.> >>> >> But, as current system works, and it does it very well, and as only > >> case> >> where we really need this is Windows... most Unices being or becoming> >> POSIX... I don't see it's smart to spend resources on becoming more > >> C...> >> Esp when "founding fathers" made it so good and so much non-C :).> >>> >> If we really need to make some approach to "their world", it's much> >> better to work on interoperability issues and thus cement our> >> first-class-citizen language status even more.> >>> >> dd> >>> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> >>> Jay:> >>>> >>> My understanding of Modula-3 is that rather than cluttering up the> >>> source code with a bunch of preprocessor directives to deal with the> >>> various changes needed by various platforms, a separate source > >>> file is> >>> used for platforms whose implementation must diverge. The m3makefile> >>> is used to control the selection of these platform sources at build> >>> time. I like this approach much better.> >>>> >>> Regards,> >>> Randy> >>>> >>>>>> Jay 2/11/2008 8:21 PM >>>> >>> So I have NOT thought this through.> >>>> >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea.> >>>> >>> Something like either the ability to prefix pragmas with a target, or> >>> an "iftarget" and "ifnottarget" pragma.> >>>> >>> Something like so:> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>>> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>> It's a small can of worms.> >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an> >>> interface/module).> >>>> >>> What about IF_OSTYPE?> >>> What about expressions?> >>> IF_TARGET NT386 OR NTAMD64> >>>> >>> IF_TARGET STARTS(NT)> >>>> >>> etc.> >>>> >>> I don't really have enough interest here to work through this, just> >>> sending out the bait...> >>>> >>> Obviously this was triggered by my happening into the odbc directory> >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling> >>> conventions with a target.> >>>> >>> This reminds me of an important point here however -- nobody else is> >>> going to make the mistake of ever having multiple calling > >>> conventions.> >>> Therefore the generality of prefixing WINAPI with NT386: is useless.> >>> Unless Mac68K support is added.> >>>> >>> And here is some rationale even. The PC and Mac evolved from "small"> >>> systems, where assembly programming was common, more people knew more> >>> lower level details and playing games with calling conventions was> >>> something anyone could do. Most other current systems are rooted in C> >>> programming. Working in C, calling conventions are generally in a> >>> hidden layer below what anyone thinks about. Therefore, the smaller> >>> number of capable people working at that level have the good sense to> >>> only have one calling convention. No more systems will evolve from> >>> "small", at least not without having observed this history. > >>> Therefore,> >>> there will no longer be multiple calling conventions.> >>>> >>> That is my theory at least.> >>>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is> >>> only x86> >> -- > >> Dragi??a Duri?? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:18:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:18:24 +0000 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: >> And I think we should fix it so that that the symbols have full source paths. >> I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. My experience using gdb suggests that the symbols have paths like foo.m3 and/or ../bar.i3 but never "full paths". You can tell gdb where to look for files, it isn't that hard, and it works. However I would really like the paths to be full paths and gdb to automatically show the source. (I'd also like a mode that shows no source and only assembly, switching off and on, presumably I'll find this in the gdb docs; it's pretty stinky that in the absence of source, you have to tell it display/i $pc but oh well...) Now, 1) Do people mind their full paths "leaking" out in binaries they give people? Make the behavior an option here? 2) When such binaries are moved across machines, presumably you are back roughly where you started. Ok. And then the same "fix"? Or does the full paths defeat any sort of search in provided paths? (It's pretty obvious where this leads if you think about the implementation -- they can look for leaf path elements in a list of directories, and they can be super aggressive and do something iterative where they try cutting off an element at a time from the start of the path and append that to each "search path", and furthermore, they can "remember" which prefixes' removal tended to work and skip right to that, however that could also lead to missing other matches, and this all rapidly explodes into many probes for files and not clearly worth it; I've never implemented a debugger but I've been a greedy/whiny user. :) ) I have not at all looked into this but I assume once I do it's not that difficult to fix. It's probably a matter of a small number of strategically placed calls to get the full path to a file. There will be the inevitable issues with the two or more different path syntaxes (essentially, mingwin and cygwin have different syntaxes, though you can setup symlinks easily enough to make them able to share each other's paths). I don't know if it plays into any "fingerprinting", and if so, that could be a total deal breaker. I kind of expect it does not. Not in anything people expect to read/write into pickles. Could be that switching this causes a rebuild of everything. Could be the full and relative paths are needed, like for cm3 -ship to work or something, or for the resulting shipped .m3exports files to work. Could be some of the builtin very well hidden stuff, the quake functions that .m3exports files use need an extra parameter, but maybe not. You know, as long as only m3cg/as get the changed paths and nothing else does... - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:38:17 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:38:17 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: done hours ago, not sure I saw the commitI still find a bit unsatisfactory.. but I guess that's plenty good. :) - Jay > From: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 12:54:15 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay, I *really* dislike the idea that you are putting target-specific > code in a subdirectory labeled Common!> > If I want to search for target-specific stuff I grep for directories > labeled by that target.> > Please, please, please think about the global picture before making > these sorts of local changes!> > Please back this change out and put this where it belongs in cm3/m3- > libs/m3core/src/C/NT386. I am happy to do it for you but I have > other things to do with my time!> > On Feb 12, 2008, at 2:05 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/02/12 14:05:18> >> > Modified files:> > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c> >> > Log message:> > fix (NT386 only)> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:03 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I don't disagree much or care much. But I like seeing my name in lights. :) - Jay > CC: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: $Id$ ?> Date: Tue, 12 Feb 2008 12:43:53 -0500> To: jayk123 at hotmail.com> > The log tells the story much better than random comments in the code.> > On Feb 12, 2008, at 1:18 AM, Jay wrote:> > > I added some files a while ago and someone either complained or > > added them, so I've been adding them since.> >> > - Jay> >> >> > > Date: Tue, 12 Feb 2008 05:20:47 +0000> > > To: m3commit at elegosoft.com> > > From: hosking at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: hosking at birch. 08/02/12 05:20:47> > >> > > Modified files:> > > cm3/m3-sys/cm3/src/: m3makefile> > >> > > Log message:> > > Let's avoid RCS id stuff shall we. Just clutters up the files...> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:55 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:55 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: Sounds good to me! - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] externs in modules instead of interfaces?> Date: Tue, 12 Feb 2008 12:42:57 -0500> To: jayk123 at hotmail.com> > The globals are gross, and not available on other platforms. Let's > just drop them...> > On Feb 12, 2008, at 12:21 PM, Jay wrote:> > > I think I just said this over the weekend, but really, I should be > > able to put in modules and not be forced to put them in an > > interface.> > Look at the cygwin Utime.i3/m3/C.c for example...> > Yeah, it's a workaround, that I'd like to remove, but it could > > easily represent a non-workaround..> > There's no real "interface/module" here, it's just that I wrote > > some of the code in C.> >> > sorry to be such an annoying whiner..but I ran into this multiple > > times over a short span of time...> >> > - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 12:01:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 11:01:51 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> References: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Message-ID: > From: hosking at cs.purdue.edu> > Aren't these all superseded by gettimeofday?> > I say just not support the global variable access.> > Utime.i3 on other platforms does not have these globals. Could be. I don't know this stuff.. They are currently used though. I didn't happen here by chance.. I'll maybe poke around. I guess this is a time to send diffs and get sign off on all platforms. OR fork the file backwards to DateLinuxOld.m3, DateBsdOld.m3, move everyone to it, then fix DateLinux/Bsd to have no data and as people test their platform move forward? And the last guy turn off the lights? (This is a philosophical and real question. The first approach is slower but moves cleanly all at once from good to good. The second approach allows a gradual migration that starts right away and leaves a cluttered history in its wake but arrives at the same place, possibly but not necessarily sooner.) Anyway, my workaround I think is working.. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 13 14:53:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:53:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <7EF4EBB4-D4F2-4964-80C0-78576D0C9812@cs.purdue.edu> On Feb 12, 2008, at 11:28 PM, Jay wrote: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. I think you will meet strong resistance here for precisely the opposite reason that you are arguing. If you want C write in C. From hosking at cs.purdue.edu Wed Feb 13 14:55:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:55:20 -0500 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: These behaviors are derivative of the GNU tools, not CM3 per se. The munged names are understood by m3gdb, which uses them to obtain type information. You don't see the munged name in m3gdb. On Feb 13, 2008, at 5:18 AM, Jay wrote: > >> And I think we should fix it so that that the symbols have full > source paths. > >> I realize they would only be correct on one machine, and > hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and > it works. > > However I would really like the paths to be full paths and gdb to > automatically show the source. > (I'd also like a mode that shows no source and only assembly, > switching off and on, presumably I'll find this in the gdb docs; > it's pretty stinky that in the absence of source, you have to tell > it display/i $pc but oh well...) > > Now, > 1) Do people mind their full paths "leaking" out in binaries they > give people? > Make the behavior an option here? > > 2) When such binaries are moved across machines, presumably you are > back roughly where you started. Ok. > And then the same "fix"? Or does the full paths defeat any sort of > search in provided paths? > (It's pretty obvious where this leads if you think about the > implementation -- they can look for leaf path elements in a list of > directories, and they can be super aggressive and do something > iterative where they try cutting off an element at a time from the > start of the path and append that to each "search path", and > furthermore, they can "remember" which prefixes' removal tended to > work and skip right to that, however that could also lead to > missing other matches, and this all rapidly explodes into many > probes for files and not clearly worth it; I've never implemented a > debugger but I've been a greedy/whiny user. :) ) > > I have not at all looked into this but I assume once I do it's not > that difficult to fix. > It's probably a matter of a small number of strategically placed > calls to get the full path to a file. > There will be the inevitable issues with the two or more different > path syntaxes (essentially, mingwin and cygwin have different > syntaxes, though you can setup symlinks easily enough to make them > able to share each other's paths). > > I don't know if it plays into any "fingerprinting", and if so, that > could be a total deal breaker. > I kind of expect it does not. Not in anything people expect to read/ > write into pickles. > Could be that switching this causes a rebuild of everything. > Could be the full and relative paths are needed, like for cm3 -ship > to work or something, or for the resulting shipped .m3exports files > to work. Could be some of the builtin very well hidden stuff, the > quake functions that .m3exports files use need an extra parameter, > but maybe not. You know, as long as only m3cg/as get the changed > paths and nothing else does... > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From wagner at elegosoft.com Wed Feb 13 14:58:28 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 14:58:28 +0100 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: <20080213145828.npvgox31w8g8k8sw@mail.elegosoft.com> Quoting Jay : > >> And I think we should fix it so that that the symbols have full > source paths. >> I realize they would only be correct on one > machine, and hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and it works. What exactly is the full path of a module? That of your private workspace (assuming you are using overrides for everything) or that in the global package pool (/usr/local/cm3/pkg/...)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 18:44:31 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 13 Feb 2008 12:44:31 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B2E62D.1E75.00D7.1@scires.com> Jay: I don't want to be offensive, but quite frankly I'm tired of continually reading your gripes about Modula-3 as a language and your pining for C. This forum is for those people interested in advancing the state of Modula-3. We don't care about C/C++/C#/etc in this forum. Those of us who are M3 zealots for the most part probably would welcome any move to divest CM3 of all underpinnings from the C world. Have you seriously studied the Modula-3 language and used it to build production software? I think some of your comments suggest that you are not a true Modula-3 programmer and that you still cling to the C-way of doing things rather than embracing the Modula-3 way. Now, I do think that most people are interested in improving things and no language is perfect, so any well-thought-out proposal for a change to the language is welcome for consideration, But in this mail list forum, I for one would appreciate less ranting about C and more constructive Modula-3. Truly, I do not want to offend you. Maybe I'm just having a bad day, but I encourage you to try and focus your posts to the advancement of Modula-3. Regards, Randy >>> Jay 2/12/2008 11:28 PM >>> > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix? There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu > Date: Tue, 12 Feb 2008 16:37:43 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "target specific pragmas"? > > > This is also an excellent reason not to permit "interfaces" to C > code inlined into MODULEs. > > Interfaces are the contract that the implementation has to live up > to. Ok, so it happens that under operating system X on architecture > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another > system, which either isn't built in C or where the function doesn't > exist, it might be convenient to implement the interface in (gasp!) > Modula-3! > > (I use this pattern as follows: on systems where Intel's Fortran > compiler is available, compile from assembly (which was generated > by ifort). On other systems, the code is implemented in Modula-3.) > > Mika > > Tony Hosking writes: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps... > > > >Maybe I am just being overly fusty... > > > >On Feb 12, 2008, at 4:35 PM, Dragi?*a Duri?* wrote: > > > >> What we _maybe_ can do... is to make some special, preprocessable > >> source > >> form, which some quake command can parse into multiple files in their > >> folders. And these file can be compiled later...Kind of how generic > >> works. > >> > >> But, as current system works, and it does it very well, and as only > >> case > >> where we really need this is Windows... most Unices being or becoming > >> POSIX... I don't see it's smart to spend resources on becoming more > >> C... > >> Esp when "founding fathers" made it so good and so much non-C :). > >> > >> If we really need to make some approach to "their world", it's much > >> better to work on interoperability issues and thus cement our > >> first-class-citizen language status even more. > >> > >> dd > >> > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > >>> Jay: > >>> > >>> My understanding of Modula-3 is that rather than cluttering up the > >>> source code with a bunch of preprocessor directives to deal with the > >>> various changes needed by various platforms, a separate source > >>> file is > >>> used for platforms whose implementation must diverge. The m3makefile > >>> is used to control the selection of these platform sources at build > >>> time. I like this approach much better. > >>> > >>> Regards, > >>> Randy > >>> > >>>>>> Jay 2/11/2008 8:21 PM >>> > >>> So I have NOT thought this through. > >>> > >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea. > >>> > >>> Something like either the ability to prefix pragmas with a target, or > >>> an "iftarget" and "ifnottarget" pragma. > >>> > >>> Something like so: > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> It's a small can of worms. > >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an > >>> interface/module). > >>> > >>> What about IF_OSTYPE? > >>> What about expressions? > >>> IF_TARGET NT386 OR NTAMD64 > >>> > >>> IF_TARGET STARTS(NT) > >>> > >>> etc. > >>> > >>> I don't really have enough interest here to work through this, just > >>> sending out the bait... > >>> > >>> Obviously this was triggered by my happening into the odbc directory > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling > >>> conventions with a target. > >>> > >>> This reminds me of an important point here however -- nobody else is > >>> going to make the mistake of ever having multiple calling > >>> conventions. > >>> Therefore the generality of prefixing WINAPI with NT386: is useless. > >>> Unless Mac68K support is added. > >>> > >>> And here is some rationale even. The PC and Mac evolved from "small" > >>> systems, where assembly programming was common, more people knew more > >>> lower level details and playing games with calling conventions was > >>> something anyone could do. Most other current systems are rooted in C > >>> programming. Working in C, calling conventions are generally in a > >>> hidden layer below what anyone thinks about. Therefore, the smaller > >>> number of capable people working at that level have the good sense to > >>> only have one calling convention. No more systems will evolve from > >>> "small", at least not without having observed this history. > >>> Therefore, > >>> there will no longer be multiple calling conventions. > >>> > >>> That is my theory at least. > >>> > >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >>> only x86 > >> -- > >> Dragi?*a Duri?* Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Feb 13 19:04:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 13 Feb 2008 12:04:15 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B3311F.4070507@wichita.edu> I haven't tried building it on any form of Windows in a long time, but m3gdb accepts unmangled Modula-3 variable (and procedure and type) names, starting with a module or interface name and supplying a fully- qualified path outside-in with procedure names and anonymous block numbers. Or, if you are stopped at a spot in the code, it will look up unqualified, unmangled names using the language's scope rules from the current point. (Hence my concern about having static links stored.) From there, you can put on additional qualifiers. Naming executable points in the code (e.g. to set breakpoints) works similarly, although that is somewhat different, and obviously, variable names aren't meaningful here. It doesn't accept paths in the filesystem, though. I'm not sure I think that would be a good idea, as it is really mostly finding things in the executable program, not the source code. It also doesn't find constant or exception names, as these currently produce no debug information. Perhaps it is time for me to modify the m3gdb web page, and also see if m3gdb can be built in Windows. Jay wrote: > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full source > paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > -- ------------------------------------------------------------- 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 Wed Feb 13 22:38:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 22:38:04 +0100 Subject: [M3devel] "Microlocation" In-Reply-To: <1202893163.3771.33.camel@faramir.m3w.org> References: <1202893163.3771.33.camel@faramir.m3w.org> Message-ID: <20080213223804.jkey99zegwks8sc4@mail.elegosoft.com> As a first step, I've added p204 to the regression tests in m3tests which contains this program: MODULE Main; IMPORT IO, IP; CONST null = IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {0,0,0,0}}; VAR addr: IP.Address; one := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {1,1,1,1}}; BEGIN addr := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {87,250,125,7}}; addr := null; addr := one; IO.Put("OK\n"); END Main. Initializers null and one work, only the one in the main body leads to code generation errors: "../src/Main.m3", line 1: 4 code generation errors 1 error encountered Any volunteers? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From darko at darko.org Thu Feb 14 01:10:18 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 11:10:18 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B2E62D.1E75.00D7.1@scires.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> Message-ID: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> I actually see some benefit to Jay's postings since they make us examine some of the differences between M3 and C and explain the benefits. These questions might be asked by any C programmer approaching the M3 language. It may be the point that Jay hasn't created and serious software in M3 and needs to be informed of the benefits. I've seen some good responses along these lines from members of the list. But Randy does have a valid point. M3 is is not just different to C, it's the antithesis of C. It's everything C isn't and the language designers went to great lengths to make it this way. It's why most of us use the language. I certainly wouldn't like to drive anyone away because they have a different point of view, but it may be a good idea to examine problems and solutions more closely and offer other solutions that 'why not do it like C'. In the case of printf, it is useful, when debugging especially, and I've created some code which takes a list of refany parameters and prints them out. It is a bit inefficient since any 'atomic' values such as integers need to be allocated but it also prints out all the fields of structures and arrays. But it is completely safe. If there were a need for a more efficient way to generated formatted strings, I'd write something else more efficient but also configurable since embedding fixed strings in your code is generally a a bad idea. On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > Jay: > > I don't want to be offensive, but quite frankly I'm tired of > continually reading your gripes about Modula-3 as a language and > your pining for C. > > This forum is for those people interested in advancing the state of > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > us who are M3 zealots for the most part probably would welcome any > move to divest CM3 of all underpinnings from the C world. > > Have you seriously studied the Modula-3 language and used it to > build production software? I think some of your comments suggest > that you are not a true Modula-3 programmer and that you still cling > to the C-way of doing things rather than embracing the Modula-3 way. > > Now, I do think that most people are interested in improving things > and no language is perfect, so any well-thought-out proposal for a > change to the language is welcome for consideration, But in this > mail list forum, I for one would appreciate less ranting about C and > more constructive Modula-3. > > Truly, I do not want to offend you. Maybe I'm just having a bad > day, but I encourage you to try and focus your posts to the > advancement of Modula-3. > > Regards, > Randy > > >>> Jay 2/12/2008 11:28 PM >>> > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. > > The debugging options seem really poor everywhere and esp. on NT386. > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full > source paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > > Other than printf'ing, I also end up getting a stack in cdb with no > symbols and then disasm in gdb to find what the functions were. That > works fine a few times, but I hope not to do it often. Somewhat > lucky I could even get a stack. Because, see, cdb is nice enough to > stop on access violations by default (such as the time/date code was > causing). gdb has a promising sounding feature, the ability to stop > on "signals", which I think an access violation would count as, oh, > but that feature isn't implemented, sorry. Ok, true, think about it > more and I can break on the toplevel exception handler in > cygwin1.dll, not sure that always works or not, it's an > implementation detail, but heck, when you are debugging, take > advantage of whatever you have. :) > > RTIO, is too verbose for me. > But darnit, I can't really have printf..puts is about the best I > could do.. > Oh, but no, since TEXT != char* even that isn't useful. > fread/fwrite maybe though. > > On a different hand (how many are there? :) ), have you looked in > m3core\src\unix? > There is just tons of dead stuff, stuff with comments about it > perhaps being wrong, "use with care". > It seemed to me maybe the point was to expose "all" of /usr/include. > Someone, other than me, sure seems to have gone overboard, like > someone using Ultrix and Linux 1.x, and then it copied around. > Heck, look at the mem* functions being commented out (and probably > using the incorrect type int) because Ultrix or somesuch didn't have > them. I uncommented them to fix a build. And notice that these > functions, again, like most of printf, are /extremely/ portable in > functionality and exact binary interface (yeah yeah, I've heard of > bcopy and bzero). > > What there was of Cstdio.i3 seemed very possibly wrong, at least on > many targets, and very doubtfully useful for anything, and I think > I've now shown unused. > > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop > rewriting them... > Or some other language, ok...not going to be solved in this forum. > To go the unpopular route (again), MS CLR/.NET among many other > things, attempts to solve this very problem. > One way to describe "interfaces" that "all" languages can > understand...at least for some subset of languages features.. > > Just as tedious btw, it is often more portable to wrap all the C > APIs in C, exposing a portable controled Modula-3 interface > independent of the precise header content. Like errno and my > get_stderr/out/in. > > - Jay > > > > To: hosking at cs.purdue.edu > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > This is also an excellent reason not to permit "interfaces" to C > > code inlined into MODULEs. > > > > Interfaces are the contract that the implementation has to live up > > to. Ok, so it happens that under operating system X on architecture > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > system, which either isn't built in C or where the function doesn't > > exist, it might be convenient to implement the interface in (gasp!) > > Modula-3! > > > > (I use this pattern as follows: on systems where Intel's Fortran > > compiler is available, compile from assembly (which was generated > > by ifort). On other systems, the code is implemented in Modula-3.) > > > > Mika > > > > Tony Hosking writes: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > >What happens when I want to bring up a system where there is no > > >C?!?! Consider the SPIN OS perhaps... > > > > > >Maybe I am just being overly fusty... > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > >> What we _maybe_ can do... is to make some special, preprocessable > > >> source > > >> form, which some quake command can parse into multiple files in > their > > >> folders. And these file can be compiled later...Kind of how > generic > > >> works. > > >> > > >> But, as current system works, and it does it very well, and as > only > > >> case > > >> where we really need this is Windows... most Unices being or > becoming > > >> POSIX... I don't see it's smart to spend resources on becoming > more > > >> C... > > >> Esp when "founding fathers" made it so good and so much non-C :). > > >> > > >> If we really need to make some approach to "their world", it's > much > > >> better to work on interoperability issues and thus cement our > > >> first-class-citizen language status even more. > > >> > > >> dd > > >> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > >>> Jay: > > >>> > > >>> My understanding of Modula-3 is that rather than cluttering up > the > > >>> source code with a bunch of preprocessor directives to deal > with the > > >>> various changes needed by various platforms, a separate source > > >>> file is > > >>> used for platforms whose implementation must diverge. The > m3makefile > > >>> is used to control the selection of these platform sources at > build > > >>> time. I like this approach much better. > > >>> > > >>> Regards, > > >>> Randy > > >>> > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > >>> So I have NOT thought this through. > > >>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good > > >>> idea. > > >>> > > >>> Something like either the ability to prefix pragmas with a > target, or > > >>> an "iftarget" and "ifnottarget" pragma. > > >>> > > >>> Something like so: > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> It's a small can of worms. > > >>> Where can they be placed? Only at "global" scope? (ie: > toplevel in an > > >>> interface/module). > > >>> > > >>> What about IF_OSTYPE? > > >>> What about expressions? > > >>> IF_TARGET NT386 OR NTAMD64 > > >>> > > >>> IF_TARGET STARTS(NT) > > >>> > > >>> etc. > > >>> > > >>> I don't really have enough interest here to work through this, > just > > >>> sending out the bait... > > >>> > > >>> Obviously this was triggered by my happening into the odbc > directory > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > calling > > >>> conventions with a target. > > >>> > > >>> This reminds me of an important point here however -- nobody > else is > > >>> going to make the mistake of ever having multiple calling > > >>> conventions. > > >>> Therefore the generality of prefixing WINAPI with NT386: is > useless. > > >>> Unless Mac68K support is added. > > >>> > > >>> And here is some rationale even. The PC and Mac evolved from > "small" > > >>> systems, where assembly programming was common, more people > knew more > > >>> lower level details and playing games with calling conventions > was > > >>> something anyone could do. Most other current systems are > rooted in C > > >>> programming. Working in C, calling conventions are generally > in a > > >>> hidden layer below what anyone thinks about. Therefore, the > smaller > > >>> number of capable people working at that level have the good > sense to > > >>> only have one calling convention. No more systems will evolve > from > > >>> "small", at least not without having observed this history. > > >>> Therefore, > > >>> there will no longer be multiple calling conventions. > > >>> > > >>> That is my theory at least. > > >>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > __thiscall is > > >>> only x86 > > >> -- > > >> Dragi??a Duri?? > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Thu Feb 14 01:34:44 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 00:34:44 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: I'll try to repeat myself less and ramble less, and stay constructive... I understand that printf type unsafety stinks and I have been bitten by it, but it is nicely terse, crude but effective, I'm going to throw away the code probably once the bug is fixed. (Ok, I like to comment out or somehow disable sometimes maybe but that is a different point, it's still not the height of production code; and yes, I realize it's a slippery slope and the next thing I'll do is use it in production code; debugging is just what I'm doing now, next up, real code). You can't just be the antithesis of C. You have to decide what it is about C that is wrong and fix it or do it over. And then of course, agreement on what is wrong. I probably see less wrong than you. Bad module system -- #include. Bad module system -- preprocesor which kills or damages other efforts at language-aware tools. Beyond this, at the moment, I am unsure. I have "argued for" C++ for further "problems" in C, but I have "grown" (or shrunk? :) ) to appreciate that C might not be as bad as I used to think. If you start over completely from scratch, you should still look at what is out there. Granted, some things are mostly arbitrary. Braces vs. begin/end. But the editors all support braces now. Until you get me to change editors (probably never), Modula-3 is always going to be less convenient. At this point you are just fighting the vast majority (except Python...). It could have gone differently, but C won. If you ignore that lowest level thing, there are places where Modula-3 is perfectly good, but doesn't take the next step. A good example I think here is it has nice "objects", however it requires they be heap allocated I think even in unsafe code. You should be able stack (or global) allocate something with "virtual functions". It seems an arbitrary limitation. I realize in safe code, you have to heap allocate more anyway, but that is a different point I think. Similarly is "multiple inheritance just of interfaces". I realize though..this hides a "vtable per interface". Maybe is much more expensive than people realize and shouldn't be provided lightly. SUBARRAY is probably example where I don't/didn't know the language well enough. And maybe the docs aren't good here. And VAR/BEGIN. Maybe I just need to reread Nelson's book. You know..reference vs. tutorial. The language reference is very very terse and that is ok. Short on examples. A tutorial that gives many examples might be good. Hey maybe I'm just the newbie in a good position to write it. (not) I guess I should be in comp.lang.c.advocacy. :) To a large extent I'm just looking for a small smart group to have a friendly intellectual discussion with. (and of course, don't mess up their code) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay's postings since they make us > examine some of the differences between M3 and C and explain the > benefits. These questions might be asked by any C programmer > approaching the M3 language. It may be the point that Jay hasn't > created and serious software in M3 and needs to be informed of the > benefits. I've seen some good responses along these lines from members > of the list.> > But Randy does have a valid point. M3 is is not just different to C, > it's the antithesis of C. It's everything C isn't and the language > designers went to great lengths to make it this way. It's why most of > us use the language.> > I certainly wouldn't like to drive anyone away because they have a > different point of view, but it may be a good idea to examine problems > and solutions more closely and offer other solutions that 'why not do > it like C'.> > In the case of printf, it is useful, when debugging especially, and > I've created some code which takes a list of refany parameters and > prints them out. It is a bit inefficient since any 'atomic' values > such as integers need to be allocated but it also prints out all the > fields of structures and arrays. But it is completely safe. If there > were a need for a more efficient way to generated formatted strings, > I'd write something else more efficient but also configurable since > embedding fixed strings in your code is generally a a bad idea.> > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be offensive, but quite frankly I'm tired of > > continually reading your gripes about Modula-3 as a language and > > your pining for C.> >> > This forum is for those people interested in advancing the state of > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealots for the most part probably would welcome any > > move to divest CM3 of all underpinnings from the C world.> >> > Have you seriously studied the Modula-3 language and used it to > > build production software? I think some of your comments suggest > > that you are not a true Modula-3 programmer and that you still cling > > to the C-way of doing things rather than embracing the Modula-3 way.> >> > Now, I do think that most people are interested in improving things > > and no language is perfect, so any well-thought-out proposal for a > > change to the language is welcome for consideration, But in this > > mail list forum, I for one would appreciate less ranting about C and > > more constructive Modula-3.> >> > Truly, I do not want to offend you. Maybe I'm just having a bad > > day, but I encourage you to try and focus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy> >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> >> > This is somewhat my point.> > When I am debugging, I really miss printf.> >> > The debugging options seem really poor everywhere and esp. on NT386.> >> > gdb has all wierded out variable names for one thing.> > And I think we should fix it so that that the symbols have full > > source paths.> > I realize they would only be correct on one machine, and hopefully > > there's a decent story for copying the files.> > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot.> >> > Other than printf'ing, I also end up getting a stack in cdb with no > > symbols and then disasm in gdb to find what the functions were. That > > works fine a few times, but I hope not to do it often. Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enough to > > stop on access violations by default (such as the time/date code was > > causing). gdb has a promising sounding feature, the ability to stop > > on "signals", which I think an access violation would count as, oh, > > but that feature isn't implemented, sorry. Ok, true, think about it > > more and I can break on the toplevel exception handler in > > cygwin1.dll, not sure that always works or not, it's an > > implementation detail, but heck, when you are debugging, take > > advantage of whatever you have. :)> >> > RTIO, is too verbose for me.> > But darnit, I can't really have printf..puts is about the best I > > could do..> > Oh, but no, since TEXT != char* even that isn't useful.> > fread/fwrite maybe though.> >> > On a different hand (how many are there? :) ), have you looked in > > m3core\src\unix?> > There is just tons of dead stuff, stuff with comments about it > > perhaps being wrong, "use with care".> > It seemed to me maybe the point was to expose "all" of /usr/include.> > Someone, other than me, sure seems to have gone overboard, like > > someone using Ultrix and Linux 1.x, and then it copied around.> > Heck, look at the mem* functions being commented out (and probably > > using the incorrect type int) because Ultrix or somesuch didn't have > > them. I uncommented them to fix a build. And notice that these > > functions, again, like most of printf, are /extremely/ portable in > > functionality and exact binary interface (yeah yeah, I've heard of > > bcopy and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, at least on > > many targets, and very doubtfully useful for anything, and I think > > I've now shown unused.> >> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> >> > But wrapping everything in Modula-3 is so tedious...> > Oh for all languages to just understand C headers so we can stop > > rewriting them...> > Or some other language, ok...not going to be solved in this forum.> > To go the unpopular route (again), MS CLR/.NET among many other > > things, attempts to solve this very problem.> > One way to describe "interfaces" that "all" languages can > > understand...at least for some subset of languages features..> >> > Just as tedious btw, it is often more portable to wrap all the C > > APIs in C, exposing a portable controled Modula-3 interface > > independent of the precise header content. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: hosking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] "target specific pragmas"?> > >> > >> > > This is also an excellent reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >> > > Interfaces are the contract that the implementation has to live up> > > to. Ok, so it happens that under operating system X on architecture> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> > > system, which either isn't built in C or where the function doesn't> > > exist, it might be convenient to implement the interface in (gasp!)> > > Modula-3!> > >> > > (I use this pattern as follows: on systems where Intel's Fortran> > > compiler is available, compile from assembly (which was generated> > > by ifort). On other systems, the code is implemented in Modula-3.)> > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> > > >What happens when I want to bring up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps...> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> > > >> > > >> What we _maybe_ can do... is to make some special, preprocessable> > > >> source> > > >> form, which some quake command can parse into multiple files in > > their> > > >> folders. And these file can be compiled later...Kind of how > > generic> > > >> works.> > > >>> > > >> But, as current system works, and it does it very well, and as > > only> > > >> case> > > >> where we really need this is Windows... most Unices being or > > becoming> > > >> POSIX... I don't see it's smart to spend resources on becoming > > more> > > >> C...> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > > >>> > > >> If we really need to make some approach to "their world", it's > > much> > > >> better to work on interoperability issues and thus cement our> > > >> first-class-citizen language status even more.> > > >>> > > >> dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rather than cluttering up > > the> > > >>> source code with a bunch of preprocessor directives to deal > > with the> > > >>> various changes needed by various platforms, a separate source> > > >>> file is> > > >>> used for platforms whose implementation must diverge. The > > m3makefile> > > >>> is used to control the selection of these platform sources at > > build> > > >>> time. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> Randy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> > > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>> > > >>> Something like either the ability to prefix pragmas with a > > target, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>> Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interface/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about expressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET STARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enough interest here to work through this, > > just> > > >>> sending out the bait...> > > >>>> > > >>> Obviously this was triggered by my happening into the odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > > >>> This reminds me of an important point here however -- nobody > > else is> > > >>> going to make the mistake of ever having multiple calling> > > >>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> > > >>> And here is some rationale even. The PC and Mac evolved from > > "small"> > > >>> systems, where assembly programming was common, more people > > knew more> > > >>> lower level details and playing games with calling conventions > > was> > > >>> something anyone could do. Most other current systems are > > rooted in C> > > >>> programming. Working in C, calling conventions are generally > > in a> > > >>> hidden layer below what anyone thinks about. Therefore, the > > smaller> > > >>> number of capable people working at that level have the good > > sense to> > > >>> only have one calling convention. No more systems will evolve > > from> > > >>> "small", at least not without having observed this history.> > > >>> Therefore,> > > >>> there will no longer be multiple calling conventions.> > > >>>> > > >>> That is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> Dragi??a Duri?? > >> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Thu Feb 14 02:09:40 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 12:09:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> M3 is the antithesis in the sense that it takes the opposite approach. C has few protections, M3 has many. M3 does examine what was wrong with C and other languages and fix them and it did a good job. The M3 design team made an explicit goal to look at features from other languages and take the best. The fact that M3 works so well is the proof. Some of the things you raise, like braces or stack allocations of objects are just features of C++ with no justification. Can you show that typing less characters is important? You say M3 is less convenient, but what is less convenient, less typing or less bugs? Do you spend most of your time typing or thinking when you write code? Should language include every feature anyone can think of? How is excluding unimportant features 'arbitrary'? Each feature must be weighed to avoid unnecessary complexity and size, which have a direct impact on compiler maintainability and language usability. Language bloat is a real problem. I doubt that anyone understands the full semantics of C++. You say that C has 'won', but in what sense? More people use it? Language design is not American Idol, it's not a question of who has the most votes. You have to do more than list features of C or C++ and your opinions on them. You have to provide some rationale as to their benefit which convinces people. On 14/02/2008, at 11:34 AM, Jay wrote: > I'll try to repeat myself less and ramble less, and stay > constructive... > > I understand that printf type unsafety stinks and I have been bitten > by it, but it is nicely terse, crude but effective, I'm going to > throw away the code probably once the bug is fixed. (Ok, I like to > comment out or somehow disable sometimes maybe but that is a > different point, it's still not the height of production code; and > yes, I realize it's a slippery slope and the next thing I'll do is > use it in production code; debugging is just what I'm doing now, > next up, real code). > > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. > > If you start over completely from scratch, you should still look at > what is out there. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. > > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. > > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. > > SUBARRAY is probably example where I don't/didn't know the language > well enough. > And maybe the docs aren't good here. > And VAR/BEGIN. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) > > I guess I should be in comp.lang.c.advocacy. :) > > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) > > - Jay > > > > > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > > From: darko at darko.org > > To: rcoleburn at scires.com > > Subject: Re: [M3devel] "target specific pragmas"? > > Date: Thu, 14 Feb 2008 11:10:18 +1100 > > > > I actually see some benefit to Jay's postings since they make us > > examine some of the differences between M3 and C and explain the > > benefits. These questions might be asked by any C programmer > > approaching the M3 language. It may be the point that Jay hasn't > > created and serious software in M3 and needs to be informed of the > > benefits. I've seen some good responses along these lines from > members > > of the list. > > > > But Randy does have a valid point. M3 is is not just different to C, > > it's the antithesis of C. It's everything C isn't and the language > > designers went to great lengths to make it this way. It's why most > of > > us use the language. > > > > I certainly wouldn't like to drive anyone away because they have a > > different point of view, but it may be a good idea to examine > problems > > and solutions more closely and offer other solutions that 'why not > do > > it like C'. > > > > In the case of printf, it is useful, when debugging especially, and > > I've created some code which takes a list of refany parameters and > > prints them out. It is a bit inefficient since any 'atomic' values > > such as integers need to be allocated but it also prints out all the > > fields of structures and arrays. But it is completely safe. If there > > were a need for a more efficient way to generated formatted strings, > > I'd write something else more efficient but also configurable since > > embedding fixed strings in your code is generally a a bad idea. > > > > > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > > > > > Jay: > > > > > > I don't want to be offensive, but quite frankly I'm tired of > > > continually reading your gripes about Modula-3 as a language and > > > your pining for C. > > > > > > This forum is for those people interested in advancing the state > of > > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > > us who are M3 zealots for the most part probably would welcome any > > > move to divest CM3 of all underpinnings from the C world. > > > > > > Have you seriously studied the Modula-3 language and used it to > > > build production software? I think some of your comments suggest > > > that you are not a true Modula-3 programmer and that you still > cling > > > to the C-way of doing things rather than embracing the Modula-3 > way. > > > > > > Now, I do think that most people are interested in improving > things > > > and no language is perfect, so any well-thought-out proposal for a > > > change to the language is welcome for consideration, But in this > > > mail list forum, I for one would appreciate less ranting about C > and > > > more constructive Modula-3. > > > > > > Truly, I do not want to offend you. Maybe I'm just having a bad > > > day, but I encourage you to try and focus your posts to the > > > advancement of Modula-3. > > > > > > Regards, > > > Randy > > > > > > >>> Jay 2/12/2008 11:28 PM >>> > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > > > This is somewhat my point. > > > When I am debugging, I really miss printf. > > > > > > The debugging options seem really poor everywhere and esp. on > NT386. > > > > > > gdb has all wierded out variable names for one thing. > > > And I think we should fix it so that that the symbols have full > > > source paths. > > > I realize they would only be correct on one machine, and hopefully > > > there's a decent story for copying the files. > > > Yeah, I know about "dir" but haven't yet formed a .gdbinit or > whatnot. > > > > > > Other than printf'ing, I also end up getting a stack in cdb with > no > > > symbols and then disasm in gdb to find what the functions were. > That > > > works fine a few times, but I hope not to do it often. Somewhat > > > lucky I could even get a stack. Because, see, cdb is nice enough > to > > > stop on access violations by default (such as the time/date code > was > > > causing). gdb has a promising sounding feature, the ability to > stop > > > on "signals", which I think an access violation would count as, > oh, > > > but that feature isn't implemented, sorry. Ok, true, think about > it > > > more and I can break on the toplevel exception handler in > > > cygwin1.dll, not sure that always works or not, it's an > > > implementation detail, but heck, when you are debugging, take > > > advantage of whatever you have. :) > > > > > > RTIO, is too verbose for me. > > > But darnit, I can't really have printf..puts is about the best I > > > could do.. > > > Oh, but no, since TEXT != char* even that isn't useful. > > > fread/fwrite maybe though. > > > > > > On a different hand (how many are there? :) ), have you looked in > > > m3core\src\unix? > > > There is just tons of dead stuff, stuff with comments about it > > > perhaps being wrong, "use with care". > > > It seemed to me maybe the point was to expose "all" of /usr/ > include. > > > Someone, other than me, sure seems to have gone overboard, like > > > someone using Ultrix and Linux 1.x, and then it copied around. > > > Heck, look at the mem* functions being commented out (and probably > > > using the incorrect type int) because Ultrix or somesuch didn't > have > > > them. I uncommented them to fix a build. And notice that these > > > functions, again, like most of printf, are /extremely/ portable in > > > functionality and exact binary interface (yeah yeah, I've heard of > > > bcopy and bzero). > > > > > > What there was of Cstdio.i3 seemed very possibly wrong, at least > on > > > many targets, and very doubtfully useful for anything, and I think > > > I've now shown unused. > > > > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > > > But wrapping everything in Modula-3 is so tedious... > > > Oh for all languages to just understand C headers so we can stop > > > rewriting them... > > > Or some other language, ok...not going to be solved in this forum. > > > To go the unpopular route (again), MS CLR/.NET among many other > > > things, attempts to solve this very problem. > > > One way to describe "interfaces" that "all" languages can > > > understand...at least for some subset of languages features.. > > > > > > Just as tedious btw, it is often more portable to wrap all the C > > > APIs in C, exposing a portable controled Modula-3 interface > > > independent of the precise header content. Like errno and my > > > get_stderr/out/in. > > > > > > - Jay > > > > > > > > > > To: hosking at cs.purdue.edu > > > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > > > From: mika at async.caltech.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > > > > > > > This is also an excellent reason not to permit "interfaces" to C > > > > code inlined into MODULEs. > > > > > > > > Interfaces are the contract that the implementation has to > live up > > > > to. Ok, so it happens that under operating system X on > architecture > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > system, which either isn't built in C or where the function > doesn't > > > > exist, it might be convenient to implement the interface in > (gasp!) > > > > Modula-3! > > > > > > > > (I use this pattern as follows: on systems where Intel's Fortran > > > > compiler is available, compile from assembly (which was > generated > > > > by ifort). On other systems, the code is implemented in > Modula-3.) > > > > > > > > Mika > > > > > > > > Tony Hosking writes: > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > >What happens when I want to bring up a system where there is no > > > > >C?!?! Consider the SPIN OS perhaps... > > > > > > > > > >Maybe I am just being overly fusty... > > > > > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > > > > > >> What we _maybe_ can do... is to make some special, > preprocessable > > > > >> source > > > > >> form, which some quake command can parse into multiple > files in > > > their > > > > >> folders. And these file can be compiled later...Kind of how > > > generic > > > > >> works. > > > > >> > > > > >> But, as current system works, and it does it very well, and > as > > > only > > > > >> case > > > > >> where we really need this is Windows... most Unices being or > > > becoming > > > > >> POSIX... I don't see it's smart to spend resources on > becoming > > > more > > > > >> C... > > > > >> Esp when "founding fathers" made it so good and so much non- > C :). > > > > >> > > > > >> If we really need to make some approach to "their world", > it's > > > much > > > > >> better to work on interoperability issues and thus cement our > > > > >> first-class-citizen language status even more. > > > > >> > > > > >> dd > > > > >> > > > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > > > >>> Jay: > > > > >>> > > > > >>> My understanding of Modula-3 is that rather than > cluttering up > > > the > > > > >>> source code with a bunch of preprocessor directives to deal > > > with the > > > > >>> various changes needed by various platforms, a separate > source > > > > >>> file is > > > > >>> used for platforms whose implementation must diverge. The > > > m3makefile > > > > >>> is used to control the selection of these platform sources > at > > > build > > > > >>> time. I like this approach much better. > > > > >>> > > > > >>> Regards, > > > > >>> Randy > > > > >>> > > > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > > > >>> So I have NOT thought this through. > > > > >>> > > > > >>> I wonder if "preprocessing" dependent only on "target" is > a good > > > > >>> idea. > > > > >>> > > > > >>> Something like either the ability to prefix pragmas with a > > > target, or > > > > >>> an "iftarget" and "ifnottarget" pragma. > > > > >>> > > > > >>> Something like so: > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> It's a small can of worms. > > > > >>> Where can they be placed? Only at "global" scope? (ie: > > > toplevel in an > > > > >>> interface/module). > > > > >>> > > > > >>> What about IF_OSTYPE? > > > > >>> What about expressions? > > > > >>> IF_TARGET NT386 OR NTAMD64 > > > > >>> > > > > >>> IF_TARGET STARTS(NT) > > > > >>> > > > > >>> etc. > > > > >>> > > > > >>> I don't really have enough interest here to work through > this, > > > just > > > > >>> sending out the bait... > > > > >>> > > > > >>> Obviously this was triggered by my happening into the odbc > > > directory > > > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > > calling > > > > >>> conventions with a target. > > > > >>> > > > > >>> This reminds me of an important point here however -- nobody > > > else is > > > > >>> going to make the mistake of ever having multiple calling > > > > >>> conventions. > > > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > > useless. > > > > >>> Unless Mac68K support is added. > > > > >>> > > > > >>> And here is some rationale even. The PC and Mac evolved from > > > "small" > > > > >>> systems, where assembly programming was common, more people > > > knew more > > > > >>> lower level details and playing games with calling > conventions > > > was > > > > >>> something anyone could do. Most other current systems are > > > rooted in C > > > > >>> programming. Working in C, calling conventions are generally > > > in a > > > > >>> hidden layer below what anyone thinks about. Therefore, the > > > smaller > > > > >>> number of capable people working at that level have the good > > > sense to > > > > >>> only have one calling convention. No more systems will > evolve > > > from > > > > >>> "small", at least not without having observed this history. > > > > >>> Therefore, > > > > >>> there will no longer be multiple calling conventions. > > > > >>> > > > > >>> That is my theory at least. > > > > >>> > > > > >>> Oh, Windows does also have __thiscall and __clrcall. > > > __thiscall is > > > > >>> only x86 > > > > >> -- > > > > >> Dragi??a Duri?? > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From mika at async.caltech.edu Thu Feb 14 02:43:13 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 17:43:13 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. A few things I know I like about M3, and don't exist in the C languages, are: * enumerated types that work well * integer subranges * arrays(!!) * arrays indexed by enumerations and subranges * absence of name mangling problems (I'm willing to accept Quake in return) * the ability to add code/declarations/types to ANY interface and not have it break a program. NO OTHER LANGUAGE (that I've heard of) HAS THIS PROPERTY. * a lot of other Java-ish properties, without being Java. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. Yes it's a lot easier to code M3 in emacs... modula3.el is a wonderful little thing to have. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. Not even C++ has virtual methods in stack-allocated objects does it? If there's a language that has a lot of arbitrary limitations in this area it's C++. It's kind of funny: if you know Modula-3, you start by wondering how C++ implements X, where X is a feature you would like but M3 lacks, and then you find that while C++ does indeed implement X', that is, X in a restricted sense, it does actually not implement X in the full generality you'd like. And for the same reasons that M3 doesn't touch it in the first place. Stack-allocated objects are an example of this. If you want stack-allocated data structures, use a RECORD and a PROCEDURE. That will give you almost exactly the same thing that a stack-allocated object gives you in C++! >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) Try Harbison's book? Or read a lot of the SRC code. Some of it is quite beautiful. About C++: do you *really* know C++? I was reading Stroustrup's book a while back and after reading four or five times "if you want to try this, ask an experienced colleague first" I gave up in disgust on trying to understand C++. There are so many odd little ways you can go wrong in C++. Sometimes assigning an object to a variable causes your program to break in mysterious and horrible ways, sometimes... C++ programmers also tend to underestimate how effective garbage collection is in simplifying things. This is different from saying "garbage collection helps you avoid memory management errors" (because you say "I am a competent C++ programmer, I never make memory management errors"). Garbage collection lets you structure your code in ways that simply is not possible if you have to worry about which part of it is going to allocate and which part is going to deallocate memory. The last and probably biggest advantage of M3 over C++ is that you can look at a program and immediately know what it means. And also know that it *can't* mean anything else. The programmer couldn't, even if he was maximally sadistic, have overloaded equals to mean not-equals, right shift to mean left shift, and left shift to mean increment. C++ lets you do this, and there are a large number of programmers out there who seemingly take advantage of every language feature they can get their hands on that lets them obscure their programs. I would summarize it as follows. Modula-3 and C++ let you compile almost exactly the same machine code. Apart from that, Modula-3 does it in a way that lets you write safe programs, and C++ does it in a way that lets you write obscure programs. Something that has become increasingly clear to me is that Modula-3 and C++ live in something of a desert. There are very few modern programming languages that are as "close to the machine" as these two. All the work that people do today (that gets any attention) is in things like Java (which is incredibly complicated, have you ever tried to compile HotSpot?) and Python (which is all right but incredibly inefficient). The more academic languages like ML and things like Self... well I won't even say anything about those. If you want a safe language that works with traditional compiler tools, Modula-3 is just about the only one out there. Finally, there is something about Randy's comment that's very true. Modula-3 is a "dead language". People that "still" use it are going to be fanatics about why they use it, rather than C or C++. If you are asked what programming language you use for development, and you answer "Modula-3" people will almost always look at you like you're crazy. We do indeed use it because it is very different from C and C++, or else we would have saved ourselves a LOT of trouble (I forget just how many existing C and C++ libraries and tools I have reimplemented just so I could stay in Modula-3) by just going with the crowd. Mika >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From mika at async.caltech.edu Thu Feb 14 03:00:46 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 18:00:46 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> I should point out that I am not trying to tell you that Modula-3 is better than C++ and you should immediately switch and stop talking about the wonderful features of C++. It's not and if you are competent enough to be coding in C++ and happy with it you should certainly not. A way to summarize what I said before is this. I do not consider myself a good programmer. Yet I sit in front of my computer trying to write software that plays with millions of dollars of other people's money. I simply do not trust myself to use a tool as sharp and unconstrained as C++. The constraints of enumerated types, subranges, typechecking at interfaces and runtime, bounds-checked arrays etc., let me sleep a bit better (but still not well). I am reminded of something my advisor's advisor once wrote, regarding the difficulty of producing large software systems: We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers. ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF CACM 15, 1972, #10, 859-866) Mika Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From wagner at elegosoft.com Thu Feb 14 09:12:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 14 Feb 2008 09:12:09 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Quoting Jay : > I'll try to repeat myself less and ramble less, and stay constructive... That would be great. It's really nice that there is much more discussion here since you joined and much more work on the Windows targets, but it would still even better if you could (a) be less sarcastic (which tends to annoy some others) and (b) think once again before hitting the send button. On some days there's even so much traffic here that I can only browse the headers (there are dozens of other mails I need to pay close attention to). > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. C is good for special kinds of system programming, with very experienced users and a code base that can still be controlled by a few minds. Large projects tend to stretch these bounds easily. For large projects taking place in a commercial environment with many teams and well-specified layers and interfaces, M3 is IMO much better suited than C (or C++, or even Java), though ironically it's not really used there (which is a pity). > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. I like C much better than C++; it's small and can be useful. C++ is way too large and complex and has never been exactly defined. When we used to program point of sale systems in the early 90s for a company here in Berlin, we had two large files of more than 1200 pages which was the upcoming C++ spec draft. Nobody has ever read even 1/10 of it. We tried about half a dozen compilers, each with nice features, but they were completely incompatible, and cost much efforts to keep code even syntactically accepted. > If you start over completely from scratch, you should still look at > what is out there. Well, we're not doing that here (starting from scratch). M3 is a well-defined and well working language, and the community here likes to use it. I'm not against language changes in general, but they need to be considered very well if we really want to improve the language. Addition of a portable 64 bit integer type for once was something that was needed, because hardware architectures and operating systems have changed. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. Any decent editor can be configured wrt. syntax highlighting and writing support (we even had that for the simple DOS editors we were using at the university together with Modula-2). Have you tried (X)Emacs? There's a really nice m3-mode for it, with highlighting and automatic completion of all language constructs. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. I'm not fighting anybody here ;-) > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. I'm not sure if that is really needed. > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. Multiple inheritance was left out of the language after long discussions because it was not really understood at that time. It may be that things have changed in this respect, but I still don't think it is. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) You can express quite a lot of unexpected things with the few language constructs. Often I'm still amazed at the ideas of other programmers when reading M3 code. > I guess I should be in comp.lang.c.advocacy. :) Yes, some of your comments would be better placed there :) > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) I think you can have that here. People are willing to discuss and think things over, but the pace may be somewhat slower than you'd like :-) (It's not as bad as with Tolkien's Ents, but still ... slow :) So, as others have noted, it's great that there is so much activity recently, but it would still be better if the discussions and comments were more focused on important language related content about M3. Nobody has accused you of malicious intentions, and you've always accepted objections and corrections by others as far as I remember. I think what is mostly needed is to slightly adapt your style of working and discussing things to become better accepted here. Don't speak out too rash, and don't commit lots of small changes too soon. Work things out and become more self-confident about the results of your work. I'm sure you can contribute many interesting things to M3. Olaf PS: Sorry if some of the above reads as if I'm your teacher ;-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 14 09:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 08:38:14 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> References: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." <200802140200.m1E20k5k062986@camembert.async.caltech.edu> Message-ID: too much to respond to right now... Yes C++ certainly allows virtual functions on stack allocated objects. class Foo{public: virtual void Bar();}; void F(){ Foo foo; foo.Bar();} works fine. You can take the address and pass it around, etc., just don't return it of course. You are right that a record with procedures might suffice.I've been using them in C lately: struct Foo_t;typedef struct Foo_t Foo_t;struct FooFunctions_t;typedef struct FooFunctions_t FooFunctions_t; struct FooFunctions_t{ // probably never any data here, it muddies the model, but maybe void (*DoSomething)(Foo_t*); void (*OrSomethingElse)(Foo_t*, size_t a, size_t b);}; struct Foo_t{ // probably never any data here, it muddies the model, but maybe const FooFunctions_t* Functions;}; // see winnt.h for exactly correct definition#define CONTAINING_RECORD(basepointer, derivedtype, basefield) ((derivedtype*) ((char*)basepointer) - (offsetof(derivedtype, basefield)))) struct Bar_t{ size_t BarData...; Foo_t Base;}; void Bar_DoSomething(Foo_t* Foo){ Bar* = CONTAINING_RECORD(Foo, Bar_t, Base) do something with Bar->BarData...} void Bar_OrSomethingElse(...) ... const FooFunctions ={ &Bar_DoSomething, &Bar_OrSomethingElse}; Foo_t* Bar_Create(){ Bar_t* Bar = (Bar_t*) calloc(1, sizeof(*Bar)); if (Bar == NULL) .... Bar->Functions = &FooFunctions; return &Bar->Base; } Foo_t* f = Bar_Create(); f->Functions->DoSomething(f); // ouch a double pointer deref, maybe code will cache the functions though CONTAINING_RECORD isn't really needed here -- Base can be at the start -- but this slightly generalized pattern supports more types of inheritance better. Presumably I can just clone this in about as much Modula-3. I'll have to try it out when I find an excuse for having "COM-like" interfaces. "I can have my C and a good module system too." :) It is a little tedious, but it keeps you off the slippery slope of C++. :) C++ has few stupid limits I can think of. One is that types (or constants) with internal linkage can't be template parameters. void F() { struct point { int a,b; }; std::vector points; // error special_debugging_class<"print me"> abc; // error } Maybe the last is fixed though. And they are both widely acknowledged to be dumb. Though I think they have an obvious rationale. (You all can guess?) True I haven't written much Modula-3. I do look around the tree some and I do see a lot gross duplication of code/effort. Yes Modula-3 enums and sets and their interaction with arrays is nice. It was actually cryptically terse to me at first but I figured it out. Optional bounds checking on arrays, good. C++ gives you what you generally need to implement sets and good arrays. C is soso. You know, the main thing you have to give up in C regarding user defined types is using those special operator characters on them. You must make explicit function calls. There is this real tension between building stuff into a language vs. building in enough facilities for people to put in libraries what they "thought" should be in the language. Same thing even goes for libraries themselves. Do you put more functionality "in" them, or provide the right composable pieces for people to build what they want. Exceptions (which nobody mentioned) are a mixed bag btw. It's not that hard really to get C correct, esp. with macros and goto (seriously!) but also not clearly worth it. Optional garbage collection maybe nice, again not so hard in C, and C++ gives you, in a sense, garbage collection and much much more along these lines via "RIAA". Also true that lots of languages don't compile to native code. The CLR does promise to be the last system to need this (at runtime or install time) and everyone else can target it. Java (VM) is similar but not general purpose enough. True that name mangling is kind of lame. Try searching for the functions, or debugging (how do I specify the name to a command line debugger? It isn't necessarily impossible, but it's another varying complexity.) Also, on the "American Idol" point, true, good point, being right and good is better than being popular, but there are network affects and some of them are desirable. It's true you don't want everyone jumping on your bandwagon, you want to keep some folks out, but having other people writing tools (editors, etc.) that you can use CAN be very nice. True again I'm a lazy typist but a frequent reader. But begin/end are no more readable than braces. It seems arbitrary, except for the network affects that make my editor favor braces. ..Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Wed, 13 Feb 2008 18:00:46 -0800> From: mika at async.caltech.edu> > > I should point out that I am not trying to tell you that Modula-3> is better than C++ and you should immediately switch and stop talking> about the wonderful features of C++. It's not and if you are> competent enough to be coding in C++ and happy with it you should> certainly not.> > A way to summarize what I said before is this. I do not consider> myself a good programmer. Yet I sit in front of my computer trying> to write software that plays with millions of dollars of other> people's money. I simply do not trust myself to use a tool as sharp> and unconstrained as C++. The constraints of enumerated types,> subranges, typechecking at interfaces and runtime, bounds-checked> arrays etc., let me sleep a bit better (but still not well).> > I am reminded of something my advisor's advisor once wrote, regarding> the difficulty of producing large software systems:> > We shall do a much better programming job, provided that we> approach the task with a full appreciation of its tremendous> difficulty, provided that we stick to modest and elegant programming> languages, provided that we respect the intrinsic limitations> of the human mind and approach the task as Very Humble Programmers.> > ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF > CACM 15, 1972, #10, 859-866)> > Mika> > > > > > > Jay writes:> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I'll try to repeat myself less and ramble less, and stay constructive...> >=20> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).> >=20> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.> >Bad module system -- #include.> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.> >Beyond this, at the moment, I am unsure.> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.> >=20> >If you start over completely from scratch, you should still look at what is=> > out there.> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.> >=20> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.> >=20> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.> >=20> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.> > And maybe the docs aren't good here.> >And VAR/BEGIN.> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)> >=20> >I guess I should be in comp.lang.c.advocacy. :)> >=20> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.> >(and of course, don't mess up their code)> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To=> >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> => >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay=> >'s postings since they make us > examine some of the differences between M3=> > and C and explain the > benefits. These questions might be asked by any C => >programmer > approaching the M3 language. It may be the point that Jay hasn=> >'t > created and serious software in M3 and needs to be informed of the > b=> >enefits. I've seen some good responses along these lines from members > of => >the list.> > But Randy does have a valid point. M3 is is not just different=> > to C, > it's the antithesis of C. It's everything C isn't and the language=> > > designers went to great lengths to make it this way. It's why most of > => >us use the language.> > I certainly wouldn't like to drive anyone away beca=> >use they have a > different point of view, but it may be a good idea to exa=> >mine problems > and solutions more closely and offer other solutions that '=> >why not do > it like C'.> > In the case of printf, it is useful, when debug=> >ging especially, and > I've created some code which takes a list of refany => >parameters and > prints them out. It is a bit inefficient since any 'atomic=> >' values > such as integers need to be allocated but it also prints out all=> > the > fields of structures and arrays. But it is completely safe. If there=> > > were a need for a more efficient way to generated formatted strings, > I=> >'d write something else more efficient but also configurable since > embedd=> >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200=> >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off=> >ensive, but quite frankly I'm tired of > > continually reading your gripes => >about Modula-3 as a language and > > your pining for C.> >> > This forum is=> > for those people interested in advancing the state of > > Modula-3. We don=> >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot=> >s for the most part probably would welcome any > > move to divest CM3 of al=> >l underpinnings from the C world.> >> > Have you seriously studied the Modu=> >la-3 language and used it to > > build production software? I think some of=> > your comments suggest > > that you are not a true Modula-3 programmer and => >that you still cling > > to the C-way of doing things rather than embracing=> > the Modula-3 way.> >> > Now, I do think that most people are interested in=> > improving things > > and no language is perfect, so any well-thought-out p=> >roposal for a > > change to the language is welcome for consideration, But => >in this > > mail list forum, I for one would appreciate less ranting about => >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend => >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo=> >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>=> > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip=> >le concern is that once we provide C APIs then C will> > > >permeate the M3=> > space more pervasively (both apps and libraries).> >> > This is somewhat m=> >y point.> > When I am debugging, I really miss printf.> >> > The debugging => >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi=> >erded out variable names for one thing.> > And I think we should fix it so => >that that the symbols have full > > source paths.> > I realize they would o=> >nly be correct on one machine, and hopefully > > there's a decent story for=> > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g=> >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta=> >ck in cdb with no > > symbols and then disasm in gdb to find what the funct=> >ions were. That > > works fine a few times, but I hope not to do it often. => >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou=> >gh to > > stop on access violations by default (such as the time/date code => >was > > causing). gdb has a promising sounding feature, the ability to stop=> > > > on "signals", which I think an access violation would count as, oh, > => >> but that feature isn't implemented, sorry. Ok, true, think about it > > m=> >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n=> >ot sure that always works or not, it's an > > implementation detail, but he=> >ck, when you are debugging, take > > advantage of whatever you have. :)> >>=> > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..=> >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char=> >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen=> >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> => >> There is just tons of dead stuff, stuff with comments about it > > perhap=> >s being wrong, "use with care".> > It seemed to me maybe the point was to e=> >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have => >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co=> >pied around.> > Heck, look at the mem* functions being commented out (and p=> >robably > > using the incorrect type int) because Ultrix or somesuch didn't=> > have > > them. I uncommented them to fix a build. And notice that these > => >> functions, again, like most of printf, are /extremely/ portable in > > fu=> >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy => >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a=> >t least on > > many targets, and very doubtfully useful for anything, and I=> > think > > I've now shown unused.> >> > > Y, the easiest way to implement t=> >he interface is to call a C > > function> > > that "just happens" to have t=> >he correct interface. But on another> >> > But wrapping everything in Modul=> >a-3 is so tedious...> > Oh for all languages to just understand C headers s=> >o we can stop > > rewriting them...> > Or some other language, ok...not goi=> >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR=> >/.NET among many other > > things, attempts to solve this very problem.> > => >One way to describe "interfaces" that "all" languages can > > understand...=> >at least for some subset of languages features..> >> > Just as tedious btw,=> > it is often more portable to wrap all the C > > APIs in C, exposing a port=> >able controled Modula-3 interface > > independent of the precise header con=> >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h=> >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: => >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3=> >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent => >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >=> >> > > Interfaces are the contract that the implementation has to live up> >=> > > to. Ok, so it happens that under operating system X on architecture> > >=> > Y, the easiest way to implement the interface is to call a C > > function>=> > > > that "just happens" to have the correct interface. But on another> > >=> > system, which either isn't built in C or where the function doesn't> > > e=> >xist, it might be convenient to implement the interface in (gasp!)> > > Mod=> >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F=> >ortran> > > compiler is available, compile from assembly (which was generat=> >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>=> > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is=> > that once we provide C APIs then C will> > > >permeate the M3 space more p=> >ervasively (both apps and libraries).> > > >What happens when I want to bri=> >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..=> >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12=> >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma=> >ybe_ can do... is to make some special, preprocessable> > > >> source> > > => >>> form, which some quake command can parse into multiple files in > > thei=> >r> > > >> folders. And these file can be compiled later...Kind of how > > g=> >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it => >does it very well, and as > > only> > > >> case> > > >> where we really nee=> >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d=> >on't see it's smart to spend resources on becoming > > more> > > >> C...> >=> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > => >> >>> > > >> If we really need to make some approach to "their world", it's=> > > > much> > > >> better to work on interoperability issues and thus cement=> > our> > > >> first-class-citizen language status even more.> > > >>> > > >>=> > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote=> >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath=> >er than cluttering up > > the> > > >>> source code with a bunch of preproce=> >ssor directives to deal > > with the> > > >>> various changes needed by var=> >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo=> >rms whose implementation must diverge. The > > m3makefile> > > >>> is used => >to control the selection of these platform sources at > > build> > > >>> ti=> >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R=> >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> => >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "=> >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>=> >> > > >>> Something like either the ability to prefix pragmas with a > > ta=> >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>=> > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END=> >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E=> >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they => >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa=> >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp=> >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S=> >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou=> >gh interest here to work through this, > > just> > > >>> sending out the ba=> >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t=> >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386=> > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >=> > >>> This reminds me of an important point here however -- nobody > > else => >is> > > >>> going to make the mistake of ever having multiple calling> > > => >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with=> > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> => >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s=> >mall"> > > >>> systems, where assembly programming was common, more people => >> > knew more> > > >>> lower level details and playing games with calling c=> >onventions > > was> > > >>> something anyone could do. Most other current s=> >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv=> >entions are generally > > in a> > > >>> hidden layer below what anyone thin=> >ks about. Therefore, the > > smaller> > > >>> number of capable people work=> >ing at that level have the good > > sense to> > > >>> only have one calling=> > convention. No more systems will evolve > > from> > > >>> "small", at leas=> >t not without having observed this history.> > > >>> Therefore,> > > >>> th=> >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That => >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc=> >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D=> >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w=> >ays with Windows Live. Get it now!>=20> >_________________________________________________________________> >Shed those extra pounds with MSN and The Biggest Loser!> >http://biggestloser.msn.com/=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I'll try to repeat myself less and rambl=> >e less, and stay constructive...
> > 
> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).
> > 
> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.
> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.
> >Bad module system -- #include.
> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.
> >Beyond this, at the moment, I am unsure.
> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<=> >BR>> > 
> >If you start over completely from scratch, you should still look at what is=> > out there.
> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.
> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.
> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.
> > 
> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.
> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.
> > 
> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.
> > 
> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.
> >  And maybe the docs aren't good here.
> >And VAR/BEGIN.
> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)
> > 
> >I guess I should be in comp.lang.c.advocacy. :)
> > 
> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.
> >(and of course, don't mess up their code)
> > 
> > - Jay


> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar=> >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar=> >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>=> >;
> I actually see some benefit to Jay's postings since they make us=> >
> examine some of the differences between M3 and C and explain the => >
> benefits. These questions might be asked by any C programmer
&=> >gt; approaching the M3 language. It may be the point that Jay hasn't
&g=> >t; created and serious software in M3 and needs to be informed of the
&=> >gt; benefits. I've seen some good responses along these lines from members => >
> of the list.
>
> But Randy does have a valid point. M=> >3 is is not just different to C,
> it's the antithesis of C. It's ev=> >erything C isn't and the language
> designers went to great lengths => >to make it this way. It's why most of
> us use the language.
>=> >
> I certainly wouldn't like to drive anyone away because they have => >a
> different point of view, but it may be a good idea to examine pr=> >oblems
> and solutions more closely and offer other solutions that '=> >why not do
> it like C'.
>
> In the case of printf, it => >is useful, when debugging especially, and
> I've created some code w=> >hich takes a list of refany parameters and
> prints them out. It is => >a bit inefficient since any 'atomic' values
> such as integers need => >to be allocated but it also prints out all the
> fields of structure=> >s and arrays. But it is completely safe. If there
> were a need for => >a more efficient way to generated formatted strings,
> I'd write som=> >ething else more efficient but also configurable since
> embedding f=> >ixed strings in your code is generally a a bad idea.
>
>
&=> >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > => >Jay:
> >
> > I don't want to be offensive, but quite fran=> >kly I'm tired of
> > continually reading your gripes about Modula=> >-3 as a language and
> > your pining for C.
> >
> => >> This forum is for those people interested in advancing the state of >R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those=> > of
> > us who are M3 zealots for the most part probably would we=> >lcome any
> > move to divest CM3 of all underpinnings from the C => >world.
> >
> > Have you seriously studied the Modula-3 la=> >nguage and used it to
> > build production software? I think some=> > of your comments suggest
> > that you are not a true Modula-3 pr=> >ogrammer and that you still cling
> > to the C-way of doing thing=> >s rather than embracing the Modula-3 way.
> >
> > Now, I => >do think that most people are interested in improving things
> > => >and no language is perfect, so any well-thought-out proposal for a
>=> > > change to the language is welcome for consideration, But in this
=> >> > mail list forum, I for one would appreciate less ranting about C => >and
> > more constructive Modula-3.
> >
> > Tru=> >ly, I do not want to offend you. Maybe I'm just having a bad
> > => >day, but I encourage you to try and focus your posts to the
> > a=> >dvancement of Modula-3.
> >
> > Regards,
> > Ran=> >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2=> >/12/2008 11:28 PM >>>
> > > >My principle concern i=> >s that once we provide C APIs then C will
> > > >permeate th=> >e M3 space more pervasively (both apps and libraries).
> >
>=> > > This is somewhat my point.
> > When I am debugging, I really=> > miss printf.
> >
> > The debugging options seem really p=> >oor everywhere and esp. on NT386.
> >
> > gdb has all wie=> >rded out variable names for one thing.
> > And I think we should f=> >ix it so that that the symbols have full
> > source paths.
>=> >; > I realize they would only be correct on one machine, and hopefully <=> >BR>> > there's a decent story for copying the files.
> > Yea=> >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>=> > >
> > Other than printf'ing, I also end up getting a stack in => >cdb with no
> > symbols and then disasm in gdb to find what the f=> >unctions were. That
> > works fine a few times, but I hope not to=> > do it often. Somewhat
> > lucky I could even get a stack. Becaus=> >e, see, cdb is nice enough to
> > stop on access violations by de=> >fault (such as the time/date code was
> > causing). gdb has a pro=> >mising sounding feature, the ability to stop
> > on "signals", wh=> >ich I think an access violation would count as, oh,
> > but that => >feature isn't implemented, sorry. Ok, true, think about it
> > mo=> >re and I can break on the toplevel exception handler in
> > cygwi=> >n1.dll, not sure that always works or not, it's an
> > implementa=> >tion detail, but heck, when you are debugging, take
> > advantage=> > of whatever you have. :)
> >
> > RTIO, is too verbose fo=> >r me.
> > But darnit, I can't really have printf..puts is about th=> >e best I
> > could do..
> > Oh, but no, since TEXT !=3D => >char* even that isn't useful.
> > fread/fwrite maybe though.
&g=> >t; >
> > On a different hand (how many are there? :) ), have yo=> >u looked in
> > m3core\src\unix?
> > There is just tons => >of dead stuff, stuff with comments about it
> > perhaps being wro=> >ng, "use with care".
> > It seemed to me maybe the point was to ex=> >pose "all" of /usr/include.
> > Someone, other than me, sure seems=> > to have gone overboard, like
> > someone using Ultrix and Linux => >1.x, and then it copied around.
> > Heck, look at the mem* functio=> >ns being commented out (and probably
> > using the incorrect type=> > int) because Ultrix or somesuch didn't have
> > them. I uncommen=> >ted them to fix a build. And notice that these
> > functions, aga=> >in, like most of printf, are /extremely/ portable in
> > function=> >ality and exact binary interface (yeah yeah, I've heard of
> > bc=> >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme=> >d very possibly wrong, at least on
> > many targets, and very dou=> >btfully useful for anything, and I think
> > I've now shown unuse=> >d.
> >
> > > Y, the easiest way to implement the inter=> >face is to call a C
> > function
> > > that "just hap=> >pens" to have the correct interface. But on another
> >
> &g=> >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for=> > all languages to just understand C headers so we can stop
> > re=> >writing them...
> > Or some other language, ok...not going to be s=> >olved in this forum.
> > To go the unpopular route (again), MS CLR=> >/.NET among many other
> > things, attempts to solve this very pr=> >oblem.
> > One way to describe "interfaces" that "all" languages c=> >an
> > understand...at least for some subset of languages feature=> >s..
> >
> > Just as tedious btw, it is often more portabl=> >e to wrap all the C
> > APIs in C, exposing a portable controled => >Modula-3 interface
> > independent of the precise header content.=> > Like errno and my
> > get_stderr/out/in.
> >
> &g=> >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.=> >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g=> >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com=> >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>=> >; > >
> > >
> > > This is also an excellent r=> >eason not to permit "interfaces" to C
> > > code inlined into M=> >ODULEs.
> > >
> > > Interfaces are the contract tha=> >t the implementation has to live up
> > > to. Ok, so it happens=> > that under operating system X on architecture
> > > Y, the eas=> >iest way to implement the interface is to call a C
> > function >R>> > > that "just happens" to have the correct interface. But on => >another
> > > system, which either isn't built in C or where th=> >e function doesn't
> > > exist, it might be convenient to imple=> >ment the interface in (gasp!)
> > > Modula-3!
> > >=> >
> > > (I use this pattern as follows: on systems where Intel's=> > Fortran
> > > compiler is available, compile from assembly (wh=> >ich was generated
> > > by ifort). On other systems, the code i=> >s implemented in Modula-3.)
> > >
> > > Mika
>=> >; > >
> > > Tony Hosking writes:
> > > >My=> > principle concern is that once we provide C APIs then C will
> > => >> >permeate the M3 space more pervasively (both apps and libraries).<=> >BR>> > > >What happens when I want to bring up a system where t=> >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&=> >gt; > > >
> > > >Maybe I am just being overly fusty=> >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P=> >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g=> >t;> What we _maybe_ can do... is to make some special, preprocessable >>> > > >> source
> > > >> form, which some=> > quake command can parse into multiple files in
> > their
>=> > > > >> folders. And these file can be compiled later...Kind of=> > how
> > generic
> > > >> works.
> > &=> >gt; >>
> > > >> But, as current system works, and i=> >t does it very well, and as
> > only
> > > >> c=> >ase
> > > >> where we really need this is Windows... most=> > Unices being or
> > becoming
> > > >> POSIX...=> > I don't see it's smart to spend resources on becoming
> > more >R>> > > >> C...
> > > >> Esp when "foundin=> >g fathers" made it so good and so much non-C :).
> > > >>=> >
> > > >> If we really need to make some approach to "the=> >ir world", it's
> > much
> > > >> better to wor=> >k on interoperability issues and thus cement our
> > > >>=> > first-class-citizen language status even more.
> > > >><=> >BR>> > > >> dd
> > > >>
> > > => >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &=> >gt; > >>> Jay:
> > > >>>
> > >=> > >>> My understanding of Modula-3 is that rather than cluttering u=> >p
> > the
> > > >>> source code with a bunch=> > of preprocessor directives to deal
> > with the
> > >=> >; >>> various changes needed by various platforms, a separate sour=> >ce
> > > >>> file is
> > > >>> us=> >ed for platforms whose implementation must diverge. The
> > m3mak=> >efile
> > > >>> is used to control the selection of th=> >ese platform sources at
> > build
> > > >>> => >time. I like this approach much better.
> > > >>>
&=> >gt; > > >>> Regards,
> > > >>> Randy >>> > > >>>
> > > >>>>>> Jay=> > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g=> >t; >>> So I have NOT thought this through.
> > > >&=> >gt;>
> > > >>> I wonder if "preprocessing" dependen=> >t only on "target" is a good
> > > >>> idea.
> &=> >gt; > >>>
> > > >>> Something like either => >the ability to prefix pragmas with a
> > target, or
> > => >> >>> an "iftarget" and "ifnottarget" pragma.
> > >=> > >>>
> > > >>> Something like so:
> >=> >; > >>>
> > > >>> <* IF_TARGET NT386 *&=> >gt;
> > > >>> <* END_IF_TARGET*>
> > &g=> >t; >>>
> > > >>>
> > > >>&g=> >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_=> >TARGET*>
> > > >>> It's a small can of worms.
&g=> >t; > > >>> Where can they be placed? Only at "global" scope?=> > (ie:
> > toplevel in an
> > > >>> interface=> >/module).
> > > >>>
> > > >>> Wha=> >t about IF_OSTYPE?
> > > >>> What about expressions? >R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > => >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g=> >t; > >>>
> > > >>> etc.
> > > => >>>>
> > > >>> I don't really have enough inte=> >rest here to work through this,
> > just
> > > >&g=> >t;> sending out the bait...
> > > >>>
> > => >> >>> Obviously this was triggered by my happening into the odb=> >c
> > directory
> > > >>> and bringing up ig=> >noring WINAPI on non-NT386 or prefixing
> > calling
> > => >> >>> conventions with a target.
> > > >>>=> >
> > > >>> This reminds me of an important point here => >however -- nobody
> > else is
> > > >>> goin=> >g to make the mistake of ever having multiple calling
> > > >=> >;>> conventions.
> > > >>> Therefore the general=> >ity of prefixing WINAPI with NT386: is
> > useless.
> > => >> >>> Unless Mac68K support is added.
> > > >>=> >;>
> > > >>> And here is some rationale even. The P=> >C and Mac evolved from
> > "small"
> > > >>>=> > systems, where assembly programming was common, more people
> > => >knew more
> > > >>> lower level details and playing ga=> >mes with calling conventions
> > was
> > > >>&g=> >t; something anyone could do. Most other current systems are
> > => >rooted in C
> > > >>> programming. Working in C, calli=> >ng conventions are generally
> > in a
> > > >>&=> >gt; hidden layer below what anyone thinks about. Therefore, the
> &g=> >t; smaller
> > > >>> number of capable people working => >at that level have the good
> > sense to
> > > >&g=> >t;> only have one calling convention. No more systems will evolve
&g=> >t; > from
> > > >>> "small", at least not without h=> >aving observed this history.
> > > >>> Therefore,
&=> >gt; > > >>> there will no longer be multiple calling convent=> >ions.
> > > >>>
> > > >>> That is=> > my theory at least.
> > > >>>
> > > >&=> >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > => >__thiscall is
> > > >>> only x86
> > > >=> >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.=> >org>
> >
> >
> > Connect and share in new way=> >s with Windows Live. Get it now!
>


Shed those ext=> >ra pounds with MSN and The Biggest Loser! >n.com/' target=3D'_new'>Learn more.> >=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 14 18:31:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 12:31:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Message-ID: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: [...many other good comments deleted...] > Multiple inheritance was left out of the language after long > discussions because it was not really understood at that time. > It may be that things have changed in this respect, but I still > don't think it is. Multiple inheritance is fine so long as it encodes only type, but *not* if it encodes representation as well. Witness single inheritance for classes in Java, versus multiple inheritance for interfaces in Java. That seems to be the general consensus these days. >> To a large extent I'm just looking for a small smart group to have >> a friendly intellectual discussion with. >> (and of course, don't mess up their code) > > I think you can have that here. People are willing to discuss and > think things over, but the pace may be somewhat slower than you'd > like :-) > (It's not as bad as with Tolkien's Ents, but still ... slow :) > So, as others have noted, it's great that there is so much activity > recently, but it would still be better if the discussions and comments > were more focused on important language related content about M3. > Nobody has accused you of malicious intentions, and you've always > accepted objections and corrections by others as far as I remember. > > I think what is mostly needed is to slightly adapt your style of > working and discussing things to become better accepted here. > Don't speak out too rash, and don't commit lots of small changes > too soon. Work things out and become more self-confident about > the results of your work. I'm sure you can contribute many interesting > things to M3. Indeed, Jay, we need your Windows energy -- M3 needs to play well on Windows if it is to serve its true purpose: a language that allows applications to be written easily that also run on a multitude of platforms (POSIX, Mach/Darwin/OS X, Windows, ...). Randy is very keen to have a *stable*, easily installed, reliable, version of CM3 running on Windows. I am not sure we have reached that goal yet, even as you have put some great work into achieving that goal. I would very much encourage you to focus your efforts on achieving that kind of stability/reliability/usability for Windows. > PS: Sorry if some of the above reads as if I'm your teacher ;-) We are all padawans Obi-wan. ;-) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Thu Feb 14 19:08:35 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:08:35 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <20080214180835.GA30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 04:28:41AM +0000, Jay wrote: > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop rewriting them... > Or some other language, ok...not going to be solved in this forum. As usual, the problem has no solutions, and there are programs that solve it. It can't be solved because a lot of C headers -- especially the standard ones -- use implementation-dependent, and often undocumented, code behind the scenes. This makes it essentially impossible to define what a "C header" is for purposes of implemetation. But it has been solved, for many practical purposes, byt a program that reads C header files and generates the interface code that's needed by other languages to interface with the C code. I'm not sure of that program's name but "swix" comes to mind. Can anyone confirm that? The program possiblyknown as swix has to be configured (in a configuration file) for the particular target language. And you'd best check the output -- it may not automagically handle *everything* C compilers can throw at it. But it is useful. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:34:27 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:34:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <20080214183427.GB30167@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: > M3 is the antithesis in the sense that it takes the opposite approach. > C has few protections, M3 has many. M3 does examine what was wrong > with C and other languages and fix them and it did a good job. The M3 > design team made an explicit goal to look at features from other > languages and take the best. The fact that M3 works so well is the > proof. > > Some of the things you raise, like braces I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and 'END'. Natural languages evolve in the direction of having the mopst-oftern used words be the shortest. This makes it possible to say muc in less space and time. And it makes it easier to get an overview of a program whose physical size is becoming inconvenient. Just haveing the code be readable and seeing enough of its context makes debugging easier. > or stack allocations of > objects are just features of C++ with no justification. Stack allocation of objects is not such a big issue in C++. But it can be a big issue in those programs where split-second real-time interaction is an issue. Yes, I know this is the traditional argument against garbage collection, and that it is usually based on FUD rather than reality. But I have recently been in close contact with a programmer of video games, and for some of them the fraction-of-a-second pauses are a real problem. He really *wants* to write his games in a decent language, and he knows that C is not one. But every time he avoids heap allocation he delays the pause. If he can delay it enough, it's a win. If he can delay it altogether, that's success. > Can you show > that typing less characters is important? You say M3 is less > convenient, but what is less convenient, less typing or less bugs? This is a false dichotomy. You may well be able to reduce typing *and* reduce bugs, just by making code more readable. I doubt that typing "PROC" instead of "PROCEDURE", for example, is likely to introdice bugs. Not typing '{' instead of "BEGIN". Using special characters and lower-case keywords is likely to reduce bugs, because it's less likely that one will be misread for another. > Do > you spend most of your time typing or thinking when you write code? I think before I write code. I don't stop thinking when I start writing code, and I like to record my thoughts as I think. The less typing I need to do, the better I can get visual feedback on my thoughts while thinking. Sometimes the typing gets so tedious I get bored and lose interest. Then extra typing causes extra bugs. > > Should language include every feature anyone can think of? No. > How is > excluding unimportant features 'arbitrary'? Each feature must be > weighed to avoid unnecessary complexity and size, which have a direct > impact on compiler maintainability and language usability. Language > bloat is a real problem. I doubt that anyone understands the full > semantics of C++. > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. Enough people use it that it has become a fixture in the programming world. If you want to reuse existing code instead of always writing new, you are pretty much forced into some kind of interfacing between C and a reasonable language. The convenience of this interfacing can well determine whether the reasonable language is feasible for a specific application. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:59:47 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:59:47 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Message-ID: <20080214185947.GC30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > Not even C++ has virtual methods in stack-allocated objects does > it? To my knowledge (as former C++ implementor), it does. But such a stack-allocated variable is of statically-known actual type, so the compiler can statically resolve all virtual methods to the actual function implementing them. And it you pass the address of such an object to another function, the other function will handle its virtual methods by the usual virtual function lookup. The only real problem is that it's a bloody disaster if you try to free one of them as if it has been dynamically allocated. But that wouldn't be a problem in a garbage-collected language. > If there's a language that has a lot of arbitrary limitations > in this area it's C++. It's kind of funny: if you know Modula-3, > you start by wondering how C++ implements X, where X is a feature > you would like but M3 lacks, and then you find that while C++ does > indeed implement X', that is, X in a restricted sense, it does > actually not implement X in the full generality you'd like. And > for the same reasons that M3 doesn't touch it in the first place. > Stack-allocated objects are an example of this. If you want > stack-allocated data structures, use a RECORD and a PROCEDURE. That > will give you almost exactly the same thing that a stack-allocated > object gives you in C++! Not quite -- you lose its ability to be considered an inheritor of another class. That's a big loss. > About C++: do you *really* know C++? I was reading Stroustrup's > book a while back and after reading four or five times "if you want > to try this, ask an experienced colleague first" I gave up in disgust > on trying to understand C++. As implementor, I suppose I might be considered an experienced colleague. > There are so many odd little ways you > can go wrong in C++. Yup. That's why I like to avoid using it. > Sometimes assigning an object to a variable > causes your program to break in mysterious and horrible ways, > sometimes... It should never have allowed those potentially type-violating assignments. > C++ programmers also tend to underestimate how effective > garbage collection is in simplifying things. This is different > from saying "garbage collection helps you avoid memory management > errors" (because you say "I am a competent C++ programmer, I never > make memory management errors"). Garbage collection lets you > structure your code in ways that simply is not possible if you have > to worry about which part of it is going to allocate and which part > is going to deallocate memory. There's code I wouldn't venture to write without built-in garbage collection. C++ throws a sop at the programmer in the form of enabling him to core reference-counting in an at least semi-automatic way, but it isn't enough. -- hendrik From rodney.bates at wichita.edu Thu Feb 14 23:56:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 16:56:13 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: <47B4C70D.4010408@wichita.edu> OK. So would my proposal 1) below suffice, that the alignment rules are a property of a type and thus the same for every variable of that type? More immediately relevant, is it true that nothing that uses LAZYALIGN rules is ever pickled? I believe current pickles will trash things badly if that happens. Fixing this without invalidating existing pickles and/or compiled code looks tricky. If nothing LAZYALIGN is pickled, I am hoping to be able to come up with a scheme that will fix pickles, not require rewriting of any already existing pickle files or recompilation of existing object code, and yet not introduce any new bugs involving old pickles/code. Maybe I should just postpone this one until after LONGINT in pickles is supported (only with STRICTALIGN, as now for other types.) Darko wrote: > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures. > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > >> It sounds like all that Mac OS X needs is for _all_ types in an entire >> program to use the liberal packing rules. Have I understood correctly? >> I would have no grief over that. >> >> Darko wrote: >> >>> The liberalised alignment rules are required for the native Mac OS >>> X API and should stay. You cannot use that API without them. I >>> think the pragma is not required and can be removed. I agree with >>> all the points you make. The effect of the modified alignment rules >>> it to allow *packed* structures to have members aligned on byte >>> boundaries. This has the effect of packing the fields in the >>> tightest arrangement allowed by the platform. This might affect >>> performance, but if the user is concerned about this they should >>> specify field bit sizes that deliver improved performance. I don't >>> see a need to specify this on a structure level, for the reasons >>> you give and because the difference isn't significant enough in the >>> case of packed structures and their physical layout and >>> restrictions are platform dependent anyway. >>> I might also add that the alignment code is currently broken on >>> I386_DARWIN. >>> - Darko >>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> >>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>> being used anywhere? >>>> >>>> It is not documented in pragmas.html. The compiler front end appears >>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>> limitations on what declarations the pragma can appear on, but these >>>> are not actually enforced.) It liberalizes the alignment rules, >>>> generally allowing scalars to start on any byte boundary. >>>> >>>> Pickles have to be able to reconstruct the layout of types as the >>>> compiler would have done it for a machine (on which a now-being-read >>>> pickle was written) with different word size and alignment properties. >>>> Currently, pickles are completely unaware of lazy alignment. It >>>> would have to be encoded in type descriptions generated by the >>>> compiler >>>> using TipeDesc and read by pickles using RTTipe. >>>> >>>> Most troubling to me is what looks like a linguistic Pandora's box. >>>> The pragma can be associated with any constant, variable, or type >>>> _declaration_ (not type definition), with the result that different >>>> values of the same type can actually be different in their alignment >>>> rules and thus their layout. Similarly for different identifiers >>>> equated to the same type. Although the effects of this could possibly >>>> be hidden from the programmer in purely safe code, not so with unsafe >>>> code. I haven't thoroughly thought this through, but seems to me to >>>> really fly in the face of the whole typing philosophy of the language. >>>> >>>> For example, if pickles were to read in an object value, and there >>>> were >1 variants of the object's type in the reading program, >>>> differing >>>> only in the alignment rules, how would it decide which one to build? >>>> In fact, ignoring pickles altogether and just looking at a single >>>> program, >>>> if the object's type doesn't actually uniquely give its memory layout, >>>> how can it be accessed correctly? >>>> >>>> Additionally, a quick look at the compiler suggests it won't generate >>>> correct code for whole record assignment when the LHS and RHS are the >>>> same type but have different alignment characteristics. >>>> >>>> The more I think about it, it seems the only workable >>>> possibilities are: >>>> >>>> 1) Require the pragma to be associated only with a type >>>> _definition_ not a >>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>>> this a >>>> property of the type that propagates to all names for the type and >>>> all variables, constants, etc. Also, this would make this property >>>> a part of the type signature that pickles uses when reading, -OR- >>>> >>>> 2) Forget it altogether. >>>> >>>> What do people think? >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 00:22:06 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:22:06 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <47B4CD1E.100@wichita.edu> Detecting use of uninitialized variables statically is undecidable, although a good many specific (and common) cases can be caught or ruled out. Detecting at runtime requires a spare bit pattern that normal values of the type don't use, or an extra bit or something--not too convenient for some types. I have always been a bit ambivalent about Modula-3's rule that every variable is initialized to some unspecified bit pattern that is a valid value of the type. I understand this is the minimum requirement to ensure type safety. But for the same price already paid to do this (runtime initialization code), we could have default initialization to a language-specified value, which would make for more consistent behavior. I have been gradually expanding the habit of writing an explicit initial value on just about everything, whether bug-free code would need it or not, just for the reduced risk of unreproduceable bugs. Of course, if the type's representation uses every bit pattern, then the rule we have has no cost, whereas a language-specified initial value would. Jay wrote: ... > Java and I presume C# have a nice feature here too where they require > the compiler to error for use of uninitialized variables, though I > suspect the specced algorithm misses some things, like: > > if (...) > initialize x > > common code > > if (same thing) > use x <== possible use of uninitialize x, not > > At least I've seen other tools (not Java/C# compilers, I don't use > those) get confused by this.. >-- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 15 00:05:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:05:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: I don't want to add fuel to the fire, but .... On Feb 14, 2008, at 1:34 PM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. There are true "real-time" garbage collectors in development and deployment now that avoid applications from seeing pauses. Modula-3 is getting better in this respect, but it is still not quite there. But, fortunately, Modula-3 provides UNTRACED objects/ references which *never* themselves cause GC. In fact, for the current CM3 implementation it would be possible to have a real-time thread run and manipulate only UNTRACED references and never ever see a GC pause -- it would keep running even while other threads are caught up by GC! >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. I don't find M3 to be unreadable at all. In fact, I find it to be very readable. > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. Who types? I use an editor that completes and indents Modula-3 code with exactly the same number of keystrokes as I use when programming in C. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. And CM3 does this very well -- that does not mean we should permeate the Modula-3 space with C'isms. > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 00:06:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:06:48 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214185947.GC30167@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> Message-ID: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> PS The C++ standard committee is actively developing the next C++ standard to include garbage collection as part of the spec. The worm has turned... On Feb 14, 2008, at 1:59 PM, hendrik at topoi.pooq.com wrote: > On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > >> Not even C++ has virtual methods in stack-allocated objects does >> it? > > To my knowledge (as former C++ implementor), it does. But such a > stack-allocated variable is of statically-known actual type, so the > compiler can statically resolve all virtual methods to the actual > function implementing them. And it you pass the address of such an > object to another function, the other function will handle its virtual > methods by the usual virtual function lookup. > > The only real problem is that it's a bloody disaster if you try to > free one of them as if it has been dynamically allocated. But that > wouldn't be a problem in a garbage-collected language. > >> If there's a language that has a lot of arbitrary limitations >> in this area it's C++. It's kind of funny: if you know Modula-3, >> you start by wondering how C++ implements X, where X is a feature >> you would like but M3 lacks, and then you find that while C++ does >> indeed implement X', that is, X in a restricted sense, it does >> actually not implement X in the full generality you'd like. And >> for the same reasons that M3 doesn't touch it in the first place. >> Stack-allocated objects are an example of this. If you want >> stack-allocated data structures, use a RECORD and a PROCEDURE. That >> will give you almost exactly the same thing that a stack-allocated >> object gives you in C++! > > Not quite -- you lose its ability to be considered an inheritor of > another class. That's a big loss. > >> About C++: do you *really* know C++? I was reading Stroustrup's >> book a while back and after reading four or five times "if you want >> to try this, ask an experienced colleague first" I gave up in disgust >> on trying to understand C++. > > As implementor, I suppose I might be considered an experienced > colleague. > >> There are so many odd little ways you >> can go wrong in C++. > > Yup. That's why I like to avoid using it. > >> Sometimes assigning an object to a variable >> causes your program to break in mysterious and horrible ways, >> sometimes... > > It should never have allowed those potentially type-violating > assignments. > >> C++ programmers also tend to underestimate how effective >> garbage collection is in simplifying things. This is different >> from saying "garbage collection helps you avoid memory management >> errors" (because you say "I am a competent C++ programmer, I never >> make memory management errors"). Garbage collection lets you >> structure your code in ways that simply is not possible if you have >> to worry about which part of it is going to allocate and which part >> is going to deallocate memory. > > There's code I wouldn't venture to write without built-in garbage > collection. C++ throws a sop at the programmer in the form of > enabling > him to core reference-counting in an at least semi-automatic way, > but it > isn't enough. > > -- hendrik From rodney.bates at wichita.edu Fri Feb 15 00:32:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:32:57 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <47B4CFA9.2060400@wichita.edu> Whether you agree with their conclusions or not, the designers of Modula-3 and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing just that. Despite having a few complaints and ambivalences here and there, I for one, think the final result is unmatched for the ways it made all the very difficult tradeoffs among highly contradictory desiderata. Jay wrote: .... > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. .... > If you start over completely from scratch, you should still look at what > is out there. -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 15 00:18:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:18:32 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> Why is LONGINT for pickles not yet supported? On Feb 14, 2008, at 5:56 PM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment > rules are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any > already existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in > pickles is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible >> with C and Unix interfaces. The alignment change was implemented >> to be supported only in packed structures as a natural and >> intuitive way to "force" alignment. You could view it as a bug >> fix to overly restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without >>>> them. I think the pragma is not required and can be removed. I >>>> agree with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have >>>> members aligned on byte boundaries. This has the effect of >>>> packing the fields in the tightest arrangement allowed by the >>>> platform. This might affect performance, but if the user is >>>> concerned about this they should specify field bit sizes that >>>> deliver improved performance. I don't see a need to specify >>>> this on a structure level, for the reasons you give and >>>> because the difference isn't significant enough in the case of >>>> packed structures and their physical layout and restrictions >>>> are platform dependent anyway. >>>> I might also add that the alignment code is currently broken >>>> on I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by >>>>> the compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type >>>>> and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 darko at darko.org Fri Feb 15 00:26:23 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:26:23 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> The alignment rules are correctly associated with a type. I think the pragma can be removed. There are no pickles anywhere of these types. On 15/02/2008, at 9:56 AM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment rules > are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any already > existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in pickles > is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible with >> C and Unix interfaces. The alignment change was implemented to be >> supported only in packed structures as a natural and intuitive way >> to "force" alignment. You could view it as a bug fix to overly >> restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without them. >>>> I think the pragma is not required and can be removed. I agree >>>> with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have members >>>> aligned on byte boundaries. This has the effect of packing the >>>> fields in the tightest arrangement allowed by the platform. >>>> This might affect performance, but if the user is concerned >>>> about this they should specify field bit sizes that deliver >>>> improved performance. I don't see a need to specify this on a >>>> structure level, for the reasons you give and because the >>>> difference isn't significant enough in the case of packed >>>> structures and their physical layout and restrictions are >>>> platform dependent anyway. >>>> I might also add that the alignment code is currently broken on >>>> I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by the >>>>> compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 Fri Feb 15 00:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:31:03 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: > I don't want to add fuel to the fire, but .... > there. But, fortunately, Modula-3 provides UNTRACED objects/ > references which *never* themselves cause GC. In fact, for the Right, "optional safety" is a nice feature of Modula-3. C# has optional safety but I think maybe in fewer ways -- optional integer overflow checks, not sure what else. Otherwise optional safety seems to be pretty rare. This does remind us -- I don't think Modula-3's integer overflow rules are as obviously safe as they could be. I think it's a target-varying thing and most targets don't check. Integer overflow has started to become a concern like buffer overflow..so probably something should be done. HOWEVER something pervasive and automatic may be too risky in terms of compatibilty with existing code. I mean Modula-3. In C and C++, for "useful suggestions", there have been two obvious patterns: Functions to add, subtract, multiple integers, that can fail. Tedious but explicit. Probably good candidates for building into the language/compiler like Word, even if they are explicit functions. Templatized types with all the operators overloaded. Also a good candidate for inclusion in the language/compiler. What to call? There is "SafeInt". I think Modula-3 has more chance of getting away with just making it so for INTEGER but I would have to read up more. In C as I understand: The encoding and overflow behavior of signed integers is undefined/implemention-defined. You could have signed magnitude, one's complement, two's complement, or anything you want. You can have any behavior for integer overflow. Some sort of "wrap around", abort(), etc. For unsigned integers, overflow is well defined, never an error, and "wraps around". In practise, signed integers are always two's complement, overflow is never an error, and "wraps around", the same or nearly the same as unsigned integers. "Wrap around" being better defined as results are taken modulo 2^(bitsize(the type)). Signed and unsigned operations often generate identical code, but not always. For example add and subtract are often identical. Comparison can be identical and then use a different conditional branch. I'm just being lazy here, if I really dig into it I could remember/re-derive the rules, though I don't know the instructions sets. (on 6502, the compare instruction only works for unsigned, you have to subtract and destroy a register, of which there are only three, though another point of view considers memory, or certain memory, as registers, yes I know that sounds plain wrong, but when all you have is a,x,y and single byte addresses have more features (addressing modes) than larger addresses...). - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 00:35:52 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:35:52 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: > From: rodney.bates at wichita.edu> > Whether you agree with their conclusions or not, the designers of Modula-3> and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing The end of Nelson's book is VERY interesting in this regard, "How Modula-3 got its spots". I had previously never thought about type name vs. structural equivalence, or even knew to ask about them. - Noam :) _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Feb 15 00:47:01 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:47:01 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> I don't really question the usefulness of any given feature, just the incremental cost of adding any given feature. One of M3's great strengths is that it is low on features, but the ones it has are powerful and well chosen. The comparison I meant in the typing discussion was between C and M3, not the length of symbols. C is a bit obsessive about source size, which was meaningful back in the day, but today is totally irrelevant. Even if you don't use macros on your editor, the amount of time spent staring and your code is much greater than the time you spend typing it. You could argue that BEGIN/END is easier to read than {/} but I think the more important point is that this issue is not a significant one. On 15/02/2008, at 5:34 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. > > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. > > -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:18:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:18:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <20080215141819.GB3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} If I had to argue, I'd argue the reverse. In fact, if it weren't for disputes about the number of spaces that are equivalent to a tab and such, I'd argue for using indentation and dispensing with BEGIN/END/{/} altogether. Somewhere I have a C++ program with all the braces left out. If you manage to supply the right braces and get it compiled, you end up with a program that will do the job of supplying the right braces. I could post it here if anyone in interested in such a curiosity. There's one language I've seen that goes in the opposite direction. Every END is followed by an arbitrary amount of text from the start of the construct it closes and a semicolon. This a WHILE loop starting WHILE toronto == montreal could end with END WHILE toronto ==; making visual matchin unambiguous. I've got friends that complain about haveing to type the name if a procerure twice in its declaration -- once at the start and once at the end. They say they keep fprgetting to modify both. But I welcome this as a useful check on long-range bracket matching. Forcing it for short-range marching, though, is clutter. -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:20:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:20:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> Message-ID: <20080215142042.GC3639@topoi.pooq.com> On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: > PS The C++ standard committee is actively developing the next C++ > standard to include garbage collection as part of the spec. What are they ever going to do with those autodecremented pointers into the middle of arrays? -- hendrik From jayk123 at hotmail.com Fri Feb 15 16:10:16 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:10:16 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: Having written a bit of Python..really just a bit..you are all privy to ALL of the Python I have ever written...I'll bite. It's fairly obvious once you write a bit of Python what goes on here. First, we all know that we all strive to indent things "correctly". Now, "correctly" can vary somewhat, but the intent is universal. Deeper lexical nesting goes with increased indentation. You can pick the indent size, spaces vs. tabs, where the braces/begin/end go, but it's still the same intent. Now, when paired with begin/end or braces, you end up with a large duplication of information. The one the compiler uses only and the ones human use more. You get to keep them in sync. Your editor might help a lot. What Python does is merely throw out half the data, and require some consistency on your part for what in other languages the compiler ignores. I don't know the exact rules, but they are probably easy to think of. That is, it could easily allow either spaces or tabs. This approach is not bad. But I have two problems: 1) again, my editor 2) it's a little wierd and hard to see when you have a whole lot of closes in a row if print if print if print nothing here vs. either C or Modula-3. Perhaps a better approach is to require "end" and require consistent indentation. Python also can't cope with an empty statement because of this plus its lack of semicolons. You have to say "pass". That's a bit of an indictment. As to tabs, the answer is very easy. Never ever use them. Lots of folks use 4 space tabs, lots of folks use 8 space tabs. I used to be a 4 space tab guy, but I gave up tabs a few years ago. The Cygwin code uses 8 space tabs and is therefore unreadable to me. (I could change my editor setting, and since the 4 space tabs are pretty rare now, ok.) To those who suggested emacs for convenient Modula-3 editing, sorry, it's not likely going to happen. I have tried vi and emacs multiple times through the years and I can't use either. I use vi just for editing commit comments, which are often pasted in to the console from notepad anyway. My "problem" is that I make heavy use of the arrows, home, end, page up, page down, control, and shift. (control can "accelerate" arrows, shift is used for selecting). And some other ingrained keyboard short cuts like control-f, F3, etc. I use Visual C++ 5.0 and its support for these keys, plus a little bit of support for indentation, is excellent. It could be that the newer versions are better, and I would like find-and-REPLACE in files, and support for unicode files, but these aren't worth it so far. Oh, and the find-in-files, minus a replace option, is excellent, just super duper, I use it constantly. Nothing else compares. The only people I try to get to change editors is people that use notepad. On PPC_DARWIN I make do with TextWrangler. It is ok. (From the BBEdit folks). On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. If anyone out there is struggling with too-basic editors such as TextEdit or whatever it's called these days, I'd recommend trying these. But if you are already using a "programmer's editor", I'll leave you alone. :) If anyone knows of something more comparable to Visual C++ 5.0 on other platforms, I'm eager to hear. (Maybe under Wine? But that requires x86 I think..) Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), but it starts up slowly on Windows, crashes a bit on Windows, and isn't being updated.. (Trying for "gentle advise" not "advocacy" here.) > > incremental cost of adding any given feature. One of M3's great I think the problem is more of multiplication than increment. How do the features interact with each other? Two features interact very very well -- destructors and exceptions. And constructors in that mix. Otherwise not certain. > C is a bit obsessive about source size, There used to be an assembler that used tabs and a competitor that used spaces. The tab guy advertised his much smaller files. :) And I think therefore faster assembling. Well, definitely much faster assembling either way, probably not because of or only because of the tabs. Yes I have that problem with procedures. And modules, and interfaces. This is where my editor and braces excel. You need to sprinkle in the matching text. You type control-brace on a brace and it shows you the matching one. Some editors do this just by moving the cursor across a brace (or paren). - Jay > Date: Fri, 15 Feb 2008 09:18:19 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote:> > I don't really question the usefulness of any given feature, just the > > incremental cost of adding any given feature. One of M3's great > > strengths is that it is low on features, but the ones it has are > > powerful and well chosen.> > > > The comparison I meant in the typing discussion was between C and M3, > > not the length of symbols. C is a bit obsessive about source size, > > which was meaningful back in the day, but today is totally irrelevant. > > Even if you don't use macros on your editor, the amount of time spent > > staring and your code is much greater than the time you spend typing > > it. You could argue that BEGIN/END is easier to read than {/}> > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/{/} > altogether.> > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces.> I could post it here if anyone in interested in such a curiosity.> > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting> WHILE toronto == montreal > could end with> END WHILE toronto ==;> making visual matchin unambiguous.> > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at the > end. They say they keep fprgetting to modify both. But I welcome this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 16:18:11 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:18:11 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. I do NOT assume existing code will get garbage collection without source change. But then again, what does the Boehm collector do? And if I write: a: array of integer; for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not what I'm used to...*) IO.PutInt(a[i]); end in Modula-3, is the codegen a) really banned from and b) really avoids "rewriting" that with pointer arithmetic? I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: unsigned array[n]; for (size_t i = 0 ; i != n ; ++i) { printf("%u\n", array[i]); } vs. unsigned array[n]; for (unsigned* p = array ; p != (array + n) ; ++p) { printf("%u\n", *p); } compilers can often do better with the first. I've heard this. I don't know why. - Jay > Date: Fri, 15 Feb 2008 09:20:42 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote:> > PS The C++ standard committee is actively developing the next C++ > > standard to include garbage collection as part of the spec.> > What are they ever going to do with those autodecremented pointers into > the middle of arrays?> > -- hendrik _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Feb 15 16:31:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 10:31:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <20080215153142.GD3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:18:11PM +0000, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. > I do NOT assume existing code will get garbage collection without source change. > But then again, what does the Boehm collector do? I don't know. I'm mostly pointing out that it will involve radical change in C++ usage. > I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: > > unsigned array[n]; > for (size_t i = 0 ; i != n ; ++i) > { printf("%u\n", array[i]); > } > > vs. > unsigned array[n]; > for (unsigned* p = array ; p != (array + n) ; ++p) > { > printf("%u\n", *p); > } > > compilers can often do better with the first. I've heard this. I don't > know why. Perhaps because it's easier to tell that array[i] is (supposed to be) within the array? I believe C spec requires this (except for some futzing with the address just one element past the array, like array+n) but it's never checked in any C compiler I know of. I once explored the possibility of performing all of these chacks in a C/C++ implementation, and concluded that it would require sufficiently different data representation from the programmers' expectations that it would be essentially useless. One of the main uses of C is to communicate with strange program libraries that use strange in-memory data structures. When they include garbage-collection into C++, I fear the result will be that in the absence of type-safety and array-bound safety, garbage collection will seem to be one more thing that causes programs to crash. -- hendrik From hosking at cs.purdue.edu Fri Feb 15 16:51:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 10:51:43 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B50EDF.8060807@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> Message-ID: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Ah, OK. I don't much delve in pickle-land. Anything I can help with? On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > 1) RTPacking.T and needs to have a separate size for LONGINT, > (which can vary independently of the size of INTEGER). > 2) Variable length values of subrange bounds found in type > descriptions (in TipeDesc.i3) can now have values beyond > what the native word size can represent. > 3) RTType.Kind.Longint (which I presume you, Tony, added recently) > is not handled by Pickles. > > I have done some coding on this, but have been interrupted. > > Tony Hosking wrote: >> Why is LONGINT for pickles not yet supported? > > -- > ------------------------------------------------------------- > 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 hosking at cs.purdue.edu Fri Feb 15 17:13:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:13:53 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <0F7203EA-6D0B-4A5D-BF81-0141ADDFC89A@cs.purdue.edu> Interior references are derived from base pointers -- they can be dealt with or treated conservatively. On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:14:36 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:14:36 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54D818D0-97A3-494E-A329-13690DF2466E@cs.purdue.edu> PS CM3 permits interior pointers into the middle of arrays. The only way they get generated is with VAR parameters, but they do exist. :-) On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:15:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:15:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <1AAD7E29-676A-4C45-93D5-7B52D08968BE@cs.purdue.edu> The directions of these postings are off-topic for the m3devel mailing list. Let's try to get back to questions of Modula-3 development. On Feb 15, 2008, at 10:10 AM, Jay wrote: > Having written a bit of Python..really just a bit..you are all > privy to ALL of the Python I have ever written...I'll bite. > > It's fairly obvious once you write a bit of Python what goes on here. > > First, we all know that we all strive to indent things "correctly". > Now, "correctly" can vary somewhat, but the intent is universal. > Deeper lexical nesting goes with increased indentation. > You can pick the indent size, spaces vs. tabs, where the braces/ > begin/end go, but it's still the same intent. > > Now, when paired with begin/end or braces, you end up with a large > duplication of information. > The one the compiler uses only and the ones human use more. > You get to keep them in sync. Your editor might help a lot. > > What Python does is merely throw out half the data, and require > some consistency on your part for what in other languages the > compiler ignores. > I don't know the exact rules, but they are probably easy to think of. > That is, it could easily allow either spaces or tabs. > > This approach is not bad. But I have two problems: > 1) again, my editor > 2) it's a little wierd and hard to see when you have a whole lot of > closes in a row > > if > print > if > print > if > print > nothing here > > vs. either C or Modula-3. > Perhaps a better approach is to require "end" and require > consistent indentation. > Python also can't cope with an empty statement because of this plus > its lack of semicolons. > You have to say "pass". That's a bit of an indictment. > > As to tabs, the answer is very easy. Never ever use them. > Lots of folks use 4 space tabs, lots of folks use 8 space tabs. > I used to be a 4 space tab guy, but I gave up tabs a few years ago. > The Cygwin code uses 8 space tabs and is therefore unreadable to me. > (I could change my editor setting, and since the 4 space tabs are > pretty rare now, ok.) > > To those who suggested emacs for convenient Modula-3 editing, > sorry, it's not likely going to happen. > I have tried vi and emacs multiple times through the years and I > can't use either. > I use vi just for editing commit comments, which are often pasted > in to the console from notepad anyway. > > My "problem" is that I make heavy use of the arrows, home, end, > page up, page down, control, and shift. > (control can "accelerate" arrows, shift is used for selecting). > And some other ingrained keyboard short cuts like control-f, F3, etc. > I use Visual C++ 5.0 and its support for these keys, plus a little > bit of support for indentation, is excellent. > It could be that the newer versions are better, and I would like > find-and-REPLACE in files, and support for unicode files, but these > aren't worth it so far. Oh, and the find-in-files, minus a replace > option, is excellent, just super duper, I use it constantly. > Nothing else compares. > > The only people I try to get to change editors is people that use > notepad. > > On PPC_DARWIN I make do with TextWrangler. It is ok. (From the > BBEdit folks). > On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. > > If anyone out there is struggling with too-basic editors such as > TextEdit or whatever it's called these days, I'd recommend trying > these. But if you are already using a "programmer's editor", I'll > leave you alone. :) > If anyone knows of something more comparable to Visual C++ 5.0 on > other platforms, I'm eager to hear. > (Maybe under Wine? But that requires x86 I think..) > > Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), > but it starts up slowly on Windows, crashes a bit on Windows, and > isn't being updated.. > > (Trying for "gentle advise" not "advocacy" here.) > > > > incremental cost of adding any given feature. One of M3's great > > I think the problem is more of multiplication than increment. > How do the features interact with each other? > Two features interact very very well -- destructors and exceptions. > And constructors in that mix. > Otherwise not certain. > > > C is a bit obsessive about source size, > > There used to be an assembler that used tabs and a competitor that > used spaces. > The tab guy advertised his much smaller files. :) And I think > therefore faster assembling. > Well, definitely much faster assembling either way, probably not > because of or only because > of the tabs. > > Yes I have that problem with procedures. And modules, and interfaces. > This is where my editor and braces excel. You need to sprinkle in > the matching text. > You type control-brace on a brace and it shows you the matching one. > Some editors do this just by moving the cursor across a brace (or > paren). > > - Jay > > > > > Date: Fri, 15 Feb 2008 09:18:19 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > > > I don't really question the usefulness of any given feature, > just the > > > incremental cost of adding any given feature. One of M3's great > > > strengths is that it is low on features, but the ones it has are > > > powerful and well chosen. > > > > > > The comparison I meant in the typing discussion was between C > and M3, > > > not the length of symbols. C is a bit obsessive about source size, > > > which was meaningful back in the day, but today is totally > irrelevant. > > > Even if you don't use macros on your editor, the amount of time > spent > > > staring and your code is much greater than the time you spend > typing > > > it. You could argue that BEGIN/END is easier to read than {/} > > > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > > disputes about the number of spaces that are equivalent to a tab and > > such, I'd argue for using indentation and dispensing with BEGIN/ > END/{/} > > altogether. > > > > Somewhere I have a C++ program with all the braces left out. If you > > manage to supply the right braces and get it compiled, you end up > > with a program that will do the job of supplying the right braces. > > I could post it here if anyone in interested in such a curiosity. > > > > There's one language I've seen that goes in the opposite direction. > > Every END is followed by an arbitrary amount of text from the > start of > > the construct it closes and a semicolon. This a WHILE loop starting > > WHILE toronto == montreal > > could end with > > END WHILE toronto ==; > > making visual matchin unambiguous. > > > > I've got friends that complain about haveing to type the name if a > > procerure twice in its declaration -- once at the start and once > at the > > end. They say they keep fprgetting to modify both. But I welcome > this > > as a useful check on long-range bracket matching. Forcing it for > > short-range marching, though, is clutter. > > > > -- hendrik > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Fri Feb 15 17:20:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:20:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54998599-6E3D-425C-BA89-7BABBD9508D6@cs.purdue.edu> On Feb 15, 2008, at 10:18 AM, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on > pointers to garbage collected types. If you check the C standard you will see that the only *defined* pointers to array elements are to the elements of the array and the "element" one index beyond the end of the array. Implementations of C are technically free to treat other pointer arithmetic however they like... :-) > I do NOT assume existing code will get garbage collection without > source change. > But then again, what does the Boehm collector do? > > And if I write: > > a: array of integer; > for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not > what I'm used to...*) > IO.PutInt(a[i]); > end > > in Modula-3, is the codegen a) really banned from and b) really avoids > "rewriting" that with pointer arithmetic? Not banned at all with the current GC. So long as a derived reference to the array exists the GC will use it to keep the array alive. From hosking at cs.purdue.edu Fri Feb 15 17:28:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:28:26 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: Rodney, Why does there need to be an entry for LONGINT in RTPacking? I would have thought all packing is done on word-sized units anyway. Each side of the connection can check BITSIZE(LONGINT) to figure out what to do presumably no differently from the way INTEGER is communicated between 32-bit and 64-bit machines. Am I missing something? -- Tony On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > Ah, OK. I don't much delve in pickle-land. Anything I can help with? > > On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >> 1) RTPacking.T and needs to have a separate size for LONGINT, >> (which can vary independently of the size of INTEGER). >> 2) Variable length values of subrange bounds found in type >> descriptions (in TipeDesc.i3) can now have values beyond >> what the native word size can represent. >> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >> is not handled by Pickles. >> >> I have done some coding on this, but have been interrupted. >> >> Tony Hosking wrote: >>> Why is LONGINT for pickles not yet supported? >> >> -- >> ------------------------------------------------------------- >> 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 rodney.bates at wichita.edu Fri Feb 15 21:50:27 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 14:50:27 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: <47B5FB13.7070407@wichita.edu> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, etc. only works for getting object layouts as on the machine executing the code, which is all that is needed when writing a pickle. When reading, Pickle code needs to know the layouts of a type both as it is on the reading machine and as it was on the machine that wrote the pickle. The type description that the compiler generates is excerpted and contains no field displacements, just lists of field types (which are either recursive type descriptions or builtin types). So it is independent of word sizes, etc. Pickles regenerates the displacements using the few target machine characteristics in a RTPacking.T It traverses a type description and simultaneously computes two sets of field displacements, both as they are on the reading machine and on the writing machine. For the latter, the value of RTPacking.T is (after a compact bit encoding) stored in the header of the pickle file. For the former, it's gotten by techniques like using BITSIZE. This is actually all done in RTTipe, part of m3core, and called by Pickle code. This is very fragile. RTTipe has to duplicate the compiler's layout behavior. There is no shared code. Making it common would involve quite a bit of rework, as the two use substantially different data structure and code organization. It will be obvious what kind of bit damage could occur if the two algorithms didn't agree. This is why I am obsessing over LAZYALIGN. I have been comparing the field displacement computations in RTTipe and in the compiler. The former is oblivious to LAZYALIGN. Note that all this is required even without any packing of small fields within words. E.G., a record with two INTEGER fields, pickled on a 32-bit machine and unpickled on a 64. Tony Hosking wrote: > Rodney, > > Why does there need to be an entry for LONGINT in RTPacking? I would > have thought all packing is done on word-sized units anyway. Each side > of the connection can check BITSIZE(LONGINT) to figure out what to do > presumably no differently from the way INTEGER is communicated between > 32-bit and 64-bit machines. Am I missing something? > > -- Tony > > On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >> >> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >> >>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>> (which can vary independently of the size of INTEGER). >>> 2) Variable length values of subrange bounds found in type >>> descriptions (in TipeDesc.i3) can now have values beyond >>> what the native word size can represent. >>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>> is not handled by Pickles. >>> >>> I have done some coding on this, but have been interrupted. >>> >>> Tony Hosking wrote: >>> >>>> Why is LONGINT for pickles not yet supported? >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > > -- ------------------------------------------------------------- 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 Fri Feb 15 22:32:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 15 Feb 2008 22:32:05 +0100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B5FB13.7070407@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> Message-ID: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Perhaps we should check-in this description somewhere near the actual code? Or is there enough documentation already? Olaf PS: Based on your description, I'd say we should abandon LAZYALIGN. Or at least put a big sticker on that it will break pickles. Quoting "Rodney M. Bates" : > The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, > etc. only works for getting object layouts as on the machine executing > the code, which is all that is needed when writing a pickle. > > When reading, Pickle code needs to know the layouts of a type both as > it is on the reading machine and as it was on the machine that wrote > the pickle. The type description that the compiler generates is > excerpted and contains no field displacements, just lists of field > types (which are either recursive type descriptions or builtin types). > So it is independent of word sizes, etc. > > Pickles regenerates the displacements using the few target machine > characteristics in a RTPacking.T It traverses a type description and > simultaneously computes two sets of field displacements, both as they > are on the reading machine and on the writing machine. For the latter, > the value of RTPacking.T is (after a compact bit encoding) stored in the > header of the pickle file. For the former, it's gotten by techniques like > using BITSIZE. This is actually all done in RTTipe, part of m3core, and > called by Pickle code. > > This is very fragile. RTTipe has to duplicate the compiler's layout > behavior. There is no shared code. Making it common would involve > quite a bit of rework, as the two use substantially different data > structure and code organization. It will be obvious what kind of bit > damage could occur if the two algorithms didn't agree. > > This is why I am obsessing over LAZYALIGN. I have been comparing the > field displacement computations in RTTipe and in the compiler. The > former is oblivious to LAZYALIGN. > > Note that all this is required even without any packing of small fields > within words. E.G., a record with two INTEGER fields, pickled on a > 32-bit machine and unpickled on a 64. > > Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I >> would have thought all packing is done on word-sized units anyway. >> Each side of the connection can check BITSIZE(LONGINT) to figure >> out what to do presumably no differently from the way INTEGER is >> communicated between 32-bit and 64-bit machines. Am I missing >> something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> > > -- > ------------------------------------------------------------- > 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 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Feb 15 23:06:24 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:06:24 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Message-ID: <47B60CE0.8050506@wichita.edu> I'll put it in comments in the code. I am sure I can fix it to handle LAZYALIGN too, just not sure whether I can do it without requiring existing pickle files to be regenerated and/or existing code that reads/writes pickles to need recompilation. Anybody on this list who has code that might be affected if pickles or compiled code were invalidated by a change? I do propose we change the way of telling the compiler to do LAZYALIGN so that it is a property of a type and affects all variables of that type. Olaf Wagner wrote: > Perhaps we should check-in this description somewhere near the > actual code? Or is there enough documentation already? > > Olaf > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > Or at least put a big sticker on that it will break pickles. > > Quoting "Rodney M. Bates" : > >> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >> etc. only works for getting object layouts as on the machine executing >> the code, which is all that is needed when writing a pickle. >> >> When reading, Pickle code needs to know the layouts of a type both as >> it is on the reading machine and as it was on the machine that wrote >> the pickle. The type description that the compiler generates is >> excerpted and contains no field displacements, just lists of field >> types (which are either recursive type descriptions or builtin types). >> So it is independent of word sizes, etc. >> >> Pickles regenerates the displacements using the few target machine >> characteristics in a RTPacking.T It traverses a type description and >> simultaneously computes two sets of field displacements, both as they >> are on the reading machine and on the writing machine. For the latter, >> the value of RTPacking.T is (after a compact bit encoding) stored in the >> header of the pickle file. For the former, it's gotten by techniques >> like >> using BITSIZE. This is actually all done in RTTipe, part of m3core, and >> called by Pickle code. >> >> This is very fragile. RTTipe has to duplicate the compiler's layout >> behavior. There is no shared code. Making it common would involve >> quite a bit of rework, as the two use substantially different data >> structure and code organization. It will be obvious what kind of bit >> damage could occur if the two algorithms didn't agree. >> >> This is why I am obsessing over LAZYALIGN. I have been comparing the >> field displacement computations in RTTipe and in the compiler. The >> former is oblivious to LAZYALIGN. >> >> Note that all this is required even without any packing of small fields >> within words. E.G., a record with two INTEGER fields, pickled on a >> 32-bit machine and unpickled on a 64. >> >> Tony Hosking wrote: >> >>> Rodney, >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> would have thought all packing is done on word-sized units anyway. >>> Each side of the connection can check BITSIZE(LONGINT) to figure >>> out what to do presumably no differently from the way INTEGER is >>> communicated between 32-bit and 64-bit machines. Am I missing >>> something? >>> >>> -- Tony >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> (which can vary independently of the size of INTEGER). >>>>> 2) Variable length values of subrange bounds found in type >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> what the native word size can represent. >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>>> is not handled by Pickles. >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> >>> >> >> -- >> ------------------------------------------------------------- >> 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 > > > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:08:46 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:08:46 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> Message-ID: <47B60D6E.8080704@wichita.edu> So how is lazy alignment invoked for these types? In my grepping and reading in the compiler, I saw internal lazy alignment booleans turned on only by the pragma. Darko wrote: > The alignment rules are correctly associated with a type. I think the > pragma can be removed. There are no pickles anywhere of these types. > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:41:09 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:41:09 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <47B61505.5080708@wichita.edu> I view this as more significant than it would first appear. More important than readability is that delimiters with several letters in all caps are more PROMINENT. This makes it quicker seeing the overall structure of a piece of code before looking at the deeper details such as which variable is being manipulated. Up to now, every person I have discussed it with who has spent enough time coding with this style of delimiters to get over their initial aversion has agreed the prominence of all caps makes the code structure easier to see quickly. Even Ada programmers who had significant prior experience in Modula-2 have preferred all caps in Ada (Ada is case- insensitive, so you can do it as you please.) As for readability, I recall seeing research some years back that showed all caps are less readable than lower case, that is, people read all caps slower and/or with less accuracy. For the delimiters, prominence is more important, especially since their vocabulary is far smaller than that of identifiers and doesn't change from program to program. As for esthetics, speaking for myself, after many years, I still think all caps reserved words are uglier than mud fences, but I happily accept that as the cost of easier scanning of code. It would be nice we had a standard character code that could handle lower case, bold face, as in the Algol 60 "publication language". That would be prominent and look great too. Of course, someone could undermine it all by making all the identifiers all caps too, loosing the quickly spotted reserved words, reducing readability where it matters more, and, IMO looking even uglier. Fortunately, Modula-3 culture seems to prevent that. Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} but I > think the more important point is that this issue is not a significant > one. -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:52:22 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:52:22 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <47B617A6.80305@wichita.edu> Darko wrote: > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. "It's what everybody is doing" motivates lemmings to jump off cliffs into the ocean and drown (according to the apparently exaggerated legend.) Thinking people need better reasons than popularity. > You have to do more than list features of C or C++ and your opinions on > them. You have to provide some rationale as to their benefit which > convinces people. Sadly, in my experience, most people are so deeply committed to lemming logic, that any attempt at engaging them in a polite but serious discussion about programming languages or giving real rationale is almost always dismissed, either as "That's just religion", or "This is what everybody is doing, ergo it has to be the right way." -- ------------------------------------------------------------- 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 mika at async.caltech.edu Fri Feb 15 23:58:55 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 14:58:55 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 13:34:27 EST." <20080214183427.GB30167@topoi.pooq.com> Message-ID: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> I just have to add a small comment on syntax, in response to how weird M3's syntax is, etc. One of the nice thing when I was teaching intro programming was that "serious" CS books (and a large fraction of academic publications) still use a kind of standard pseudocode that is based on Algol. And that pseudocode looks a lot more like Modula-3 than it looks like C! No explanation of braces or the fact that when you see "=" in the pseudocode you want "==" in the machine-readable version, and when you see ":=" you want "=". What your video game developer friend needs is to do exercise #12 in section 2.3.5 in Knuth. (There are references to three existing solutions in the answer key.) Mika hendrik at topoi.pooq.com writes: >On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > >I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and >'END'. > >Natural languages evolve in the direction of having the mopst-oftern >used words be the shortest. This makes it possible to say muc in less >space and time. And it makes it easier to get an overview of a >program whose physical size is becoming inconvenient. Just haveing >the code be readable and seeing enough of its context makes >debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > >Stack allocation of objects is not such a big issue in C++. But it can >be a big issue in those programs where split-second real-time >interaction is an issue. Yes, I know this is the traditional argument >against garbage collection, and that it is usually based on FUD rather >than reality. But I have recently been in close contact with a >programmer of video games, and for some of them the fraction-of-a-second >pauses are a real problem. He really *wants* to write his games in a >decent language, and he knows that C is not one. > >But every time he avoids heap allocation he delays the pause. If >he can delay it enough, it's a win. If he can delay it altogether, >that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing >*and* reduce bugs, just by making code more readable. > >I doubt that typing "PROC" instead of "PROCEDURE", for example, is >likely to introdice bugs. Not typing '{' instead of "BEGIN". Using >special characters and lower-case keywords is likely to reduce bugs, >because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > >I think before I write code. I don't stop thinking when I start >writing code, and I like to record my thoughts as I think. The less >typing I need to do, the better I can get visual feedback on my >thoughts while thinking. Sometimes the typing gets so tedious I get >bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > >No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > >Enough people use it that it has become a fixture in the programming >world. If you want to reuse existing code instead of always writing >new, you are pretty much forced into some kind of interfacing between C >and a reasonable language. The convenience of this interfacing can well >determine whether the reasonable language is feasible for a specific >application. > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 00:17:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 18:17:41 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> References: <20080214183427.GB30167@topoi.pooq.com> <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> Message-ID: <20080215231741.GA4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: > > What your video game developer friend needs is to do exercise #12 > in section 2.3.5 in Knuth. (There are references to three existing > solutions in the answer key.) Is that the one one completely concurrent garbage collection? Unfortunately, he wants to write video games, not implement programming languages. But ... I think he's tempted. I still feel I have to warn him of the time I wanted to write an applocation and got side-tracked into writing the language in which the application would be easy to write. I never got back to the application. I don't even remember what it was. That was in the 1960's. I'm still stuck on languages. -- hendrik From darko at darko.org Sat Feb 16 00:34:47 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:34:47 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <25955172-E857-4B24-8D51-3701C7353687@darko.org> I'm sticking to my view about lexical arbitrariness, but on that basis, I'd really like to see an alternate syntax for M3, one that looks almost exactly like C, but roughly keeps the existing statement form. I think it would make the language much more palatable to C programmers and the like and would remove what is a silly barrier to broader adaption. We could call the syntax 'Modula-C'. On 16/02/2008, at 1:18 AM, hendrik at topoi.pooq.com wrote: > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: >> I don't really question the usefulness of any given feature, just the >> incremental cost of adding any given feature. One of M3's great >> strengths is that it is low on features, but the ones it has are >> powerful and well chosen. >> >> The comparison I meant in the typing discussion was between C and M3, >> not the length of symbols. C is a bit obsessive about source size, >> which was meaningful back in the day, but today is totally >> irrelevant. >> Even if you don't use macros on your editor, the amount of time spent >> staring and your code is much greater than the time you spend typing >> it. You could argue that BEGIN/END is easier to read than {/} > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/ > {/} > altogether. > > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces. > I could post it here if anyone in interested in such a curiosity. > > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting > WHILE toronto == montreal > could end with > END WHILE toronto ==; > making visual matchin unambiguous. > > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at > the > end. They say they keep fprgetting to modify both. But I welcome > this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter. > > -- hendrik From mika at async.caltech.edu Sat Feb 16 00:38:09 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:38:09 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Fri, 15 Feb 2008 14:50:27 CST." <47B5FB13.7070407@wichita.edu> Message-ID: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Hi Rodney, I am not sure if I am reading your email entirely correctly, but I think so... you're trying to figure out things like offsets so the Pickle runtime can re-build arbitrary data structures. When we were doing some concurrent programming in my group about ten years ago, we were using a user-level threading system (very similar but not identical to the old user-level threads in M3) and we needed to figure out the location of the stack pointer in a C jmp_buf. We just wrote a program to do it... Could you do that? Write some arbitrary data whose bit pattern you know to a field, cast it to char * (or some such), and search for the bit pattern? Do it over and over with random data, and there you go... Mika "Rodney M. Bates" writes: >The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >etc. only works for getting object layouts as on the machine executing >the code, which is all that is needed when writing a pickle. > >When reading, Pickle code needs to know the layouts of a type both as >it is on the reading machine and as it was on the machine that wrote >the pickle. The type description that the compiler generates is >excerpted and contains no field displacements, just lists of field >types (which are either recursive type descriptions or builtin types). >So it is independent of word sizes, etc. > >Pickles regenerates the displacements using the few target machine >characteristics in a RTPacking.T It traverses a type description and >simultaneously computes two sets of field displacements, both as they >are on the reading machine and on the writing machine. For the latter, >the value of RTPacking.T is (after a compact bit encoding) stored in the >header of the pickle file. For the former, it's gotten by techniques like >using BITSIZE. This is actually all done in RTTipe, part of m3core, and >called by Pickle code. > >This is very fragile. RTTipe has to duplicate the compiler's layout >behavior. There is no shared code. Making it common would involve >quite a bit of rework, as the two use substantially different data >structure and code organization. It will be obvious what kind of bit >damage could occur if the two algorithms didn't agree. > >This is why I am obsessing over LAZYALIGN. I have been comparing the >field displacement computations in RTTipe and in the compiler. The >former is oblivious to LAZYALIGN. > >Note that all this is required even without any packing of small fields >within words. E.G., a record with two INTEGER fields, pickled on a >32-bit machine and unpickled on a 64. > >Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I would >> have thought all packing is done on word-sized units anyway. Each side >> of the connection can check BITSIZE(LONGINT) to figure out what to do >> presumably no differently from the way INTEGER is communicated between >> 32-bit and 64-bit machines. Am I missing something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> > >-- >------------------------------------------------------------- >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 darko at darko.org Sat Feb 16 00:41:51 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:41:51 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B60D6E.8080704@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> <47B60D6E.8080704@wichita.edu> Message-ID: <385E6BF4-B476-4060-9EAD-DE1DCC74A2D9@darko.org> It's turned on at the platform level only. The result is that packed structures are packed as tightly as possible. On 16/02/2008, at 9:08 AM, Rodney M. Bates wrote: > So how is lazy alignment invoked for these types? In my grepping > and reading > in the compiler, I saw internal lazy alignment booleans turned on only > by the pragma. > > Darko wrote: >> The alignment rules are correctly associated with a type. I think >> the pragma can be removed. There are no pickles anywhere of these >> types. > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Sat Feb 16 00:51:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:51:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 10:34:47 +1100." <25955172-E857-4B24-8D51-3701C7353687@darko.org> Message-ID: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Darko writes: >I'm sticking to my view about lexical arbitrariness, but on that >basis, I'd really like to see an alternate syntax for M3, one that >looks almost exactly like C, but roughly keeps the existing statement >form. I think it would make the language much more palatable to C >programmers and the like and would remove what is a silly barrier to >broader adaption. We could call the syntax 'Modula-C'. This is getting a bit silly, and I apologize to everyone reading this about wasting their time, but I just have to show you the following file. It is a header file from the original sources of "sh" (this copy is from 4.3 TAHOE UNIX, but of course the code is much older than that). After that, blok.c, an example of "Bournegol" in use. So, you want the opposite, huh? Mika /* mac.h 4.3 87/10/26 */ # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #define LOCAL static #define PROC extern #define TYPE typedef #define STRUCT TYPE struct #define UNION TYPE union #define REG register #define IF if( #define THEN ){ #define ELSE } else { #define ELIF } else if ( #define FI ;} #define BEGIN { #define END } #define SWITCH switch( #define IN ){ #define ENDSW } #define FOR for( #define WHILE while( #define DO ){ #define OD ;} #define REP do{ #define PER }while( #undef DONE #define DONE ); #define LOOP for(;;){ #define POOL } #define SKIP ; #define DIV / #define REM % #define NEQ ^ #define ANDF && #define ORF || #define TRUE (-1) #define FALSE 0 #define LOBYTE 0377 #define STRIP 0177 #define QUOTE 0200 #define EOF 0 #define NL '\n' #define SP ' ' #define LQ '`' #define RQ '\'' #define MINUS '-' #define COLON ':' #ifndef lint static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; #endif # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #include "defs.h" /* * storage allocator * (circular first fit strategy) */ #define BUSY 01 #define busy(x) (Rcheat((x)->word)&BUSY) POS brkincr=BRKINCR; BLKPTR blokp; /*current search pointer*/ BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ ADDRESS alloc(nbytes) POS nbytes; { REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); LOOP INT c=0; REG BLKPTR p = blokp; REG BLKPTR q; REP IF !busy(p) THEN WHILE !busy(q = p->word) DO p->word = q->word OD IF ADR(q)-ADR(p) >= rbytes THEN blokp = BLK(ADR(p)+rbytes); IF q > blokp THEN blokp->word = p->word; FI p->word=BLK(Rcheat(blokp)|BUSY); return(ADR(p+1)); FI FI q = p; p = BLK(Rcheat(p->word)&~BUSY); PER p>q ORF (c++)==0 DONE addblok(rbytes); POOL } VOID addblok(reqd) POS reqd; { IF stakbas!=staktop THEN REG STKPTR rndstak; REG BLKPTR blokstak; pushstak(0); rndstak=round(staktop,BYTESPERWORD); blokstak=BLK(stakbas)-1; blokstak->word=stakbsy; stakbsy=blokstak; bloktop->word=BLK(Rcheat(rndstak)|BUSY); bloktop=BLK(rndstak); FI reqd += brkincr; reqd &= ~(brkincr-1); blokp=bloktop; bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); bloktop->word=BLK(ADR(end)+1); BEGIN REG STKPTR stakadr=STK(bloktop+2); staktop=movstr(stakbot,stakadr); stakbas=stakbot=stakadr; END } VOID free(ap) BLKPTR ap; { REG BLKPTR p; IF (p=ap) ANDF pword) &= ~BUSY; FI } #ifdef DEBUG chkbptr(ptr) BLKPTR ptr; { INT exf=0; REG BLKPTR p = end; REG BLKPTR q; INT us=0, un=0; LOOP q = Rcheat(p->word)&~BUSY; IF p==ptr THEN exf++ FI IF qbloktop THEN abort(3) FI IF p==bloktop THEN break FI IF busy(p) THEN us += q-p; ELSE un += q-p; FI IF p>=q THEN abort(4) FI p=q; POOL IF exf==0 THEN abort(1) FI prn(un); prc(SP); prn(us); prc(NL); } #endif From mika at async.caltech.edu Sat Feb 16 00:56:00 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:56:00 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Fri, 15 Feb 2008 18:17:41 EST." <20080215231741.GA4216@topoi.pooq.com> Message-ID: <200802152356.m1FNu0F3034075@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: >> >> What your video game developer friend needs is to do exercise #12 >> in section 2.3.5 in Knuth. (There are references to three existing >> solutions in the answer key.) > >Is that the one one completely concurrent garbage collection? Right, I think that's what Tony was (indirectly) referring to, as well. The publication dates on the three solutions range from 1975 to 1978... > >Unfortunately, he wants to write video games, not implement programming >languages. But ... I think he's tempted. > >I still feel I have to warn him of the time I wanted to write an >applocation and got side-tracked into writing the language in which the >application would be easy to write. I never got back to the >application. I don't even remember what it was. That was in the >1960's. I'm still stuck on languages. And, if you ask me, languages are still stuck! > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:18:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:18:30 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B61505.5080708@wichita.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <47B61505.5080708@wichita.edu> Message-ID: <20080216001830.GB4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 04:41:09PM -0600, Rodney M. Bates wrote: > I view this as more significant than it would first appear. More > important than readability is that delimiters with several letters > in all caps are more PROMINENT. This makes it quicker seeing the > overall structure of a piece of code before looking at the deeper > details such as which variable is being manipulated. > > Up to now, every person I have discussed it with who has spent enough > time coding with this style of delimiters to get over their initial > aversion has agreed the prominence of all caps makes the code structure > easier to see quickly. Even Ada programmers who had significant prior > experience in Modula-2 have preferred all caps in Ada (Ada is case- > insensitive, so you can do it as you please.) > > As for readability, I recall seeing research some years back that > showed all caps are less readable than lower case, that is, people > read all caps slower and/or with less accuracy. For the delimiters, > prominence is more important, especially since their vocabulary is > far smaller than that of identifiers and doesn't change from program > to program. As long as you don't have both else and elsf as keywords in the same language! It works find in lower-case but is hopeless in upper. > As for esthetics, speaking for myself, after many years, I still think > all caps reserved words are uglier than mud fences, but I happily accept > that as the cost of easier scanning of code. > > It would be nice we had a standard character code that could handle > lower case, bold face, as in the Algol 60 "publication language". > That would be prominent and look great too. Really, there should be nothing preventing us from writing editors that display all-upper-case words as red lower-case words, and m3-to-ps converters that print them as bold-face lower-case. -- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:25:15 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:25:15 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <25955172-E857-4B24-8D51-3701C7353687@darko.org> <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <20080216002515.GC4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:51:43PM -0800, Mika Nystrom wrote: > Darko writes: > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? Yeah. Steve Bourne did an Algol 68 variant in Cambridge before he went to Bell Labs. He did his bit here to make C look more like Algol 68C. Except A68 allows things to be a lot more terse than here. I think A68 had the right idea about syntax. Except that it was horrible to parse. -- hendrik From darko at darko.org Sat Feb 16 08:30:29 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 18:30:29 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> I'm not sure what you're getting at or if I'm missing something witty. I've said the form of the keywords makes little or no difference in my opinion. In my mail you quote I say there should be a C like syntax for M3 as well as the existing one. I wasn't being sarcastic. It's a matter of taste. I write in both all the time and it doesn't have any impact on me, I go almost entirely by indentation, which I think is very important. The indentation is pretty awful in code you posted but it could me my mailer. On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > Darko writes: >> I'm sticking to my view about lexical arbitrariness, but on that >> basis, I'd really like to see an alternate syntax for M3, one that >> looks almost exactly like C, but roughly keeps the existing statement >> form. I think it would make the language much more palatable to C >> programmers and the like and would remove what is a silly barrier to >> broader adaption. We could call the syntax 'Modula-C'. > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? > > Mika > > > /* mac.h 4.3 87/10/26 */ > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #define LOCAL static > #define PROC extern > #define TYPE typedef > #define STRUCT TYPE struct > #define UNION TYPE union > #define REG register > > #define IF if( > #define THEN ){ > #define ELSE } else { > #define ELIF } else if ( > #define FI ;} > > #define BEGIN { > #define END } > #define SWITCH switch( > #define IN ){ > #define ENDSW } > #define FOR for( > #define WHILE while( > #define DO ){ > #define OD ;} > #define REP do{ > #define PER }while( > #undef DONE > #define DONE ); > #define LOOP for(;;){ > #define POOL } > > > #define SKIP ; > #define DIV / > #define REM % > #define NEQ ^ > #define ANDF && > #define ORF || > > #define TRUE (-1) > #define FALSE 0 > #define LOBYTE 0377 > #define STRIP 0177 > #define QUOTE 0200 > > #define EOF 0 > #define NL '\n' > #define SP ' ' > #define LQ '`' > #define RQ '\'' > #define MINUS '-' > #define COLON ':' > > > > #ifndef lint > static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; > #endif > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #include "defs.h" > > > /* > * storage allocator > * (circular first fit strategy) > */ > > #define BUSY 01 > #define busy(x) (Rcheat((x)->word)&BUSY) > > POS brkincr=BRKINCR; > BLKPTR blokp; /*current search pointer*/ > BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ > > > > ADDRESS alloc(nbytes) > POS nbytes; > { > REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); > > LOOP INT c=0; > REG BLKPTR p = blokp; > REG BLKPTR q; > REP IF !busy(p) > THEN WHILE !busy(q = p->word) DO p->word = q->word OD > IF ADR(q)-ADR(p) >= rbytes > THEN blokp = BLK(ADR(p)+rbytes); > IF q > blokp > THEN blokp->word = p->word; > FI > p->word=BLK(Rcheat(blokp)|BUSY); > return(ADR(p+1)); > FI > FI > q = p; p = BLK(Rcheat(p->word)&~BUSY); > PER p>q ORF (c++)==0 DONE > addblok(rbytes); > POOL > } > > VOID addblok(reqd) > POS reqd; > { > IF stakbas!=staktop > THEN REG STKPTR rndstak; > REG BLKPTR blokstak; > > pushstak(0); > rndstak=round(staktop,BYTESPERWORD); > blokstak=BLK(stakbas)-1; > blokstak->word=stakbsy; stakbsy=blokstak; > bloktop->word=BLK(Rcheat(rndstak)|BUSY); > bloktop=BLK(rndstak); > FI > reqd += brkincr; reqd &= ~(brkincr-1); > blokp=bloktop; > bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); > bloktop->word=BLK(ADR(end)+1); > BEGIN > REG STKPTR stakadr=STK(bloktop+2); > staktop=movstr(stakbot,stakadr); > stakbas=stakbot=stakadr; > END > } > > VOID free(ap) > BLKPTR ap; > { > REG BLKPTR p; > > IF (p=ap) ANDF p THEN Lcheat((--p)->word) &= ~BUSY; > FI > } > > #ifdef DEBUG > chkbptr(ptr) > BLKPTR ptr; > { > INT exf=0; > REG BLKPTR p = end; > REG BLKPTR q; > INT us=0, un=0; > > LOOP > q = Rcheat(p->word)&~BUSY; > IF p==ptr THEN exf++ FI > IF qbloktop THEN abort(3) FI > IF p==bloktop THEN break FI > IF busy(p) > THEN us += q-p; > ELSE un += q-p; > FI > IF p>=q THEN abort(4) FI > p=q; > POOL > IF exf==0 THEN abort(1) FI > prn(un); prc(SP); prn(us); prc(NL); > } > #endif From jayk123 at hotmail.com Sat Feb 16 08:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 07:34:27 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: > The indentation is pretty awful in code you posted but > it could me my mailer. Yep..it was eight space tabs at every level for me. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Feb 16 10:42:28 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 01:42:28 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 18:30:29 +1100." <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> "If Steve Bourne could turn C into Algol using cpp, I'm sure you can figure out how to turn Algol[Modula] back into C using <...>"... If you think it would help acceptance of Modula-3, I don't see why not? I copied the code exactly the way it came off the old half-inch tape from Berkeley. Darko writes: >I'm not sure what you're getting at or if I'm missing something witty. >I've said the form of the keywords makes little or no difference in my >opinion. In my mail you quote I say there should be a C like syntax >for M3 as well as the existing one. I wasn't being sarcastic. It's a >matter of taste. I write in both all the time and it doesn't have any >impact on me, I go almost entirely by indentation, which I think is >very important. The indentation is pretty awful in code you posted but >it could me my mailer. > >On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: ... From darko at darko.org Sat Feb 16 11:10:40 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 21:10:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> References: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> Message-ID: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> If you like the idea, maybe you'd like join me in working out what such a syntax would look like? Note that I want to keep the structure the same, so no assignments in expressions, for example. Also, would C programmers revolt at not having post and pre increment, also inside expressions (as statements would be ok)? Requiring some sort of EVAL statement? I guess the big question is whether removing these things would make the whole idea unacceptable to the target audience. Does the Algol syntax serve a purpose in making it clear that it isn't C? On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > > "If Steve Bourne could turn C into Algol using cpp, I'm sure you > can figure out how to turn Algol[Modula] back into C using <...>"... > > If you think it would help acceptance of Modula-3, I don't see why > not? > > I copied the code exactly the way it came off the old half-inch > tape from Berkeley. > > Darko writes: >> I'm not sure what you're getting at or if I'm missing something >> witty. >> I've said the form of the keywords makes little or no difference in >> my >> opinion. In my mail you quote I say there should be a C like syntax >> for M3 as well as the existing one. I wasn't being sarcastic. It's a >> matter of taste. I write in both all the time and it doesn't have any >> impact on me, I go almost entirely by indentation, which I think is >> very important. The indentation is pretty awful in code you posted >> but >> it could me my mailer. >> >> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > ... From jayk123 at hotmail.com Sat Feb 16 20:30:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:30:01 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*) Without those lines commented out, only ever one file gets compiled. The process create for the second cm3cg fails (but not for the first as). Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything. Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle? I figured this out with strace. The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly. For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 20:37:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:37:46 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 21:31:53 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 20:31:53 +0000 Subject: [M3devel] FW: NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: seems to have gotten truncated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Feb 17 06:43:38 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 21:43:38 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sat, 16 Feb 2008 21:10:40 +1100." <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> Message-ID: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Well I used to be mostly a C programmer but I long since weaned myself off that syntax :) Your point of the post- and pre-increment might be a bit difficult for C programmers to stomach, but... well it is probably hard to tell what programmers will hate and what they will love. Wouldn't a way to go about it be to take the Modula-3 BNF and modify the rules as needed? Would you like to be able to convert back and forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case all the keywords, convert the braces appropriately (a bit tricky since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO BEGIN END, so braces map only to the ENDs, not BEGINs (for the most part)). Type "attributes"(is that the right word?) are also an area where Modula-3 is significantly different from the C family. In C, you write int *a, *b, c; we have REF INTEGER a, b; INTEGER c; And arrays? VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; I prefer Algol syntax myself but I could definitely see that there might be people who would prefer a syntax mapped to C. One might be able to sneak Modula-3 into places where it wouldn't otherwise be used... Would it be possible to make "m3c" close enough in syntax that some simple C header files could be processed? Am I just being ridiculous now? A compiler that can process both C and Modula-3 in the same file? Python, by the way, provides some interesting hooks for C programs to interact with the Python garbage collector. Something similar could be done here. (But there is far less reason to write C code to plug into M3 than there is to write it to plug into Python.) Mika Darko writes: >If you like the idea, maybe you'd like join me in working out what >such a syntax would look like? Note that I want to keep the structure >the same, so no assignments in expressions, for example. Also, would C >programmers revolt at not having post and pre increment, also inside >expressions (as statements would be ok)? Requiring some sort of EVAL >statement? I guess the big question is whether removing these things >would make the whole idea unacceptable to the target audience. Does >the Algol syntax serve a purpose in making it clear that it isn't C? > > >On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > >> >> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >> can figure out how to turn Algol[Modula] back into C using <...>"... >> >> If you think it would help acceptance of Modula-3, I don't see why >> not? >> >> I copied the code exactly the way it came off the old half-inch >> tape from Berkeley. >> >> Darko writes: >>> I'm not sure what you're getting at or if I'm missing something >>> witty. >>> I've said the form of the keywords makes little or no difference in >>> my >>> opinion. In my mail you quote I say there should be a C like syntax >>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>> matter of taste. I write in both all the time and it doesn't have any >>> impact on me, I go almost entirely by indentation, which I think is >>> very important. The indentation is pretty awful in code you posted >>> but >>> it could me my mailer. >>> >>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >> ... From hendrik at topoi.pooq.com Sun Feb 17 07:29:03 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 01:29:03 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217062903.GA24856@topoi.pooq.com> On Sat, Feb 16, 2008 at 09:43:38PM -0800, Mika Nystrom wrote: > > > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; The declarator syntax in C was a mistake. Let's not perpetuate it. -- hendrik From jayk123 at hotmail.com Sun Feb 17 09:47:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 08:47:52 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Nevermind, of course, I should have known, even though I'm working on fixing the stat struct (probably to blame for files always being out of date) and thought I might have it right, I should have known, I have it too small and the next variable is getting overwritten, causing us to close(0).. If I put in arbitrary large padding at the end, it grows enough to cover up the problem..now to get it right.. null_fd and the entire struct stat need not be globals, just the dev field...of course optimize that and I would have a stack corruption instead, not sure it would have been harder or easier to figure out..I should have started at the bottom of the system and gotten all the headers right in the first place....sigh. VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN null_done := TRUE; null_fd := Unix.open( M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, ADR(null_stat)); RTIO.PutText("2 null_fd is " & Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); and then close 0 here oops IF result # 0 THEN null_fd := -1 END From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 17 10:30:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 10:30:01 +0100 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Quoting Jay : > Nevermind, of course, I should have known, even though I'm working > on fixing the stat struct (probably to blame for files always being > out of date) and thought I might have it right, I should have known, > I have it too small and the next variable is getting overwritten, > causing us to close(0).. Yes, the C interfaces are the place where ports are most likely to be broken. There are no checks there; it's completely unsafe. I wonder if one could write a checker that compares the sizes of the most important structures in C and M3, but that would probably not be trivial. > If I put in arbitrary large padding at the end, it grows enough to > cover up the problem..now to get it right.. > null_fd and the entire struct stat need not be globals, just the dev > field...of course optimize that and I would have a stack corruption > instead, not sure it would have been harder or easier to figure > out..I should have started at the bottom of the system and gotten > all the headers right in the first place....sigh. Yes, it's always a good idea to get the base right at the start. On the other hand, you will usually return there during ant porting, regardless of your best efforts ;-) > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; > > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > null_done := TRUE; null_fd := Unix.open( > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > and then close 0 here oops IF result # 0 THEN null_fd := -1 END [Could you try to persuade your mailer to produce a readable text form besides HTML? If not it looks like that :-(] Anyway, as your previous posting asked about a change in general POSIX support files, I'd really advise you to try out such changes on at least one other platform (e.g. Linux), however innocuous they may seem. Thanks for all the work, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Feb 17 10:57:15 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 09:57:15 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Message-ID: No need for a change in platform-independent code now. My question was sort of "can anyone else try this out, I'm lazy". But I looked up the definition of dup/dup2 and decided Cygwin wasn't doing anything wrong, looked at the strace, saw we were closing 0, started some RTIO... and if IsDebuggerPresent, DebugBreak and finally realized of course what was happening. (the debugging options are really not good. I couldn't even see the globals in gdb, neither of the obvious names worked...I was doing a little debugging in cdb as well and found a crashing bug in it, very very very unusual) Writing a struct checker should actually be pretty easy. The trick is probably mainly to limit the dependencies so it can work when much of the system is broken, or to use a cross strategy if possible..it helps that NT386 supports two sort of platforms/targets/configurations, so you can cross with a smaller context switch. :) I'm not sure how to get field offsets in Modula-3 but if you get as far as having the compiler working, it can generate C with assertions as to sizes and offsets. The compiler's dependency on stat is "the problem". Again I like that idea of wrapping C in C, to expose a portable interface.Of course, it's inefficient. The direct exporting of C interfaces, when they are /correct/ is pretty efficient. NT386GNU should be just about "self hosting" now -- able to build a "min" distribution and then "upgrade". Small hacks in pylib.py needed that might break Win32, no big deal, it's "just the scripts". :) Next steps will be: a) consider changing the "naming conventions" it's still foo.lib and not foo.a, foo.dll and not foo.so. b) see if X Windows works (stuff builds) c) the small set and bitmap bugs (running the tests!) I do have one more commit to enable stuff, a small one, where the Slash is determine at runtime in slightly more code. SL is already determined at runtime, but M3Path maps naming convensions (foo.lib vs. libfoo.a, foo.dll vs. foo.so) to also determine slashes. It might even work if they were escaped, but what I have is a good solution. (if I figure I can ramble here, since I'm on topic. :) ) - Jay > Date: Sun, 17 Feb 2008 10:30:01 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] NT386GNU status/fishing for guesses..> > Quoting Jay :> > > Nevermind, of course, I should have known, even though I'm working > > on fixing the stat struct (probably to blame for files always being > > out of date) and thought I might have it right, I should have known, > > I have it too small and the next variable is getting overwritten, > > causing us to close(0)..> > Yes, the C interfaces are the place where ports are most likely to> be broken. There are no checks there; it's completely unsafe.> I wonder if one could write a checker that compares the sizes of> the most important structures in C and M3, but that would probably> not be trivial.> > > If I put in arbitrary large padding at the end, it grows enough to > > cover up the problem..now to get it right..> > null_fd and the entire struct stat need not be globals, just the dev > > field...of course optimize that and I would have a stack corruption > > instead, not sure it would have been harder or easier to figure > > out..I should have started at the bottom of the system and gotten > > all the headers right in the first place....sigh.> > Yes, it's always a good idea to get the base right at the start.> On the other hand, you will usually return there during ant porting,> regardless of your best efforts ;-)> > > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER;> >> > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > > null_done := TRUE; null_fd := Unix.open( > > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > > and then close 0 here oops IF result # 0 THEN null_fd := -1 END> > [Could you try to persuade your mailer to produce a readable text> form besides HTML? If not it looks like that :-(]> > Anyway, as your previous posting asked about a change in general POSIX> support files, I'd really advise you to try out such changes on at> least one other platform (e.g. Linux), however innocuous they may seem.> > Thanks for all the work,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 17 14:16:59 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 08:16:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> Message-ID: <20080217131659.GA25696@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > [...many other good comments deleted...] > > > >Multiple inheritance was left out of the language after long > >discussions because it was not really understood at that time. > >It may be that things have changed in this respect, but I still > >don't think it is. > > Multiple inheritance is fine so long as it encodes only type, but > *not* if it encodes representation as well. Witness single > inheritance for classes in Java, versus multiple inheritance for > interfaces in Java. That seems to be the general consensus these days. Multiple inheritance could still work under the constraint that no two ancestors provided different representations for any feature. I'd count separate definitions of a virtual function as different even if their code happens to be textually identical. Then an interface (like in Java) would be nothing but a class that has no representation. Then to build a class you could combine little chunks of representation, much as a linker combines little pieces of program. and multiple MODULEs can implement parts of the same INTERFACE. And by combining chunks chunks differently you could build classes with different behaviour. This would make more code-sharing is feasible, without a crisis in semantics. I could consider adding the following clause, because I think it would help modularity (though I'm not sure it's necessary): But if both ancestors have the same defined representation but they are ultimately inherited from the same definition, I'd count them as the same (though I could be argued out of this clause). Actully, I suppose this might be necessary because all objects inherit representation from OBJECT, and a general rule might be better than a special case for OBJECT. -- hendrik From wagner at elegosoft.com Sun Feb 17 14:31:38 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 14:31:38 +0100 Subject: [M3devel] Integration of package-local tests Message-ID: <20080217143138.izfhuwm2yosw0g4w@mail.elegosoft.com> As some of you may have noticed, the regression test scope is increasing steadily though slowly. During recent days I tried to integrate the existing tests that are local to some packages. It's working this way: During a complete package build run with ./scripts/do-cm3-all.sh -report build all pacakges are compiled and the results reported on the web server (see http://www.opencm3.net/logs/package-status.html). For an easy overview, packages that compile OK are coloured green, packages with errors are red, and those unsupported on a certain platform are marked yellow. Recently a fourth column has been added which reports the results of tests if they are present. Tests are assumed if in the package root a sub directory test or tests exists, and if beneath that src/m3makefile is found. The fourth column will be yellow if this is not the case. If tests are present, they are compiled and (probably) run with cm3 -build -override -DROOT=$ROOT -DRUN A sample tests/src/m3makefile from package arithmetic looks like this: import("libm3") import("tempfiles") import("arithmetic") implementation("TestWordEx") implementation("TestBits") %[more test sources omitted] implementation("TestFunctional") Module("Test") program("test") if defined("RUN") r = q_exec( "." & SL & "test" ) write( CR, "program returned ", r, CR ) end The last four lines will run the compiled test executable. Of course, more complex setups are possible there. The test result column will be red if the tests do not compile or another fatal error is detected, orange, if something is output to stderr, and green in all other cases. At least for the actual test candidate an appropriate override should be defined like this: override("arithmetic", PACKAGE_DIR & SL & ".." & SL & "..") As usual, this should be done in the src/m3overrides file. To give a slightly more complex example, the tests for patternmatching are performed thus: if defined("RUN") r = q_exec( "." & SL & "test-regex -unix < .." & SL & "tests.input" ) write( CR, "program returned ", r, CR ) r = q_exec( "." & SL & "test-regex -unix < .." & SL & "testsdiffer.input" ) write( CR, "program returned ", r, CR ) end Here, two test runs are made with different input files. I'd like to encourage all contributors to adapt or extend their packages accordingly, so that more things can be automatically validated every night on miscellaneous platforms. Of course it would also be great if the encountered errors get fixed :-) Thanks for your attention and cooperation, Olaf PS: I'll attach one current package report file for those too lazy to follow the links ;-) PPS: Of course you can run the tests and generate the reports locally, too. During development I've used something like HTML_REPORT=/var/tmp/cm3-pkg-report-FreeBSD4-2008-02-17.html \ time ./scripts/do-cm3-all.sh -report build 2>&1 | tee plog to generate a complete report with a fixed name and log all actions in plog. PPPS: The actual implementation of report generation is in scripts/pkgmap.sh. So you can use -report with almost all build scripts. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sun Feb 17 18:39:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 18:39:07 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> It's now more than two weeks since I asked for participants, and none but the elego tests have shown up in the tinderbox since then. So I think it may be time for a reminder :-) I don't want to hurry anyone, but if anything does not work as expected or described or someone needs help getting tinderbox reports transfered, don't hesitate to contact me. I'd really love to see more platforms than FreeBSD and Linux and the occasional DARWIN tested on a regular basis. Olaf PS: No need to apologize for anyone who maybe hasn't found the time yet to setup the test runs. I really understand that there are many more important matters. Quoting Olaf Wagner : > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression testing >> would help and should be introduced. Tests should be run daily/nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox > /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Sun Feb 17 19:04:44 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 17 Feb 2008 12:04:44 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> References: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Message-ID: <47B8773C.50803@wichita.edu> Well, in the case of pickles, there is not currently any known bit pattern to look for. Everything is either user's data, which must be allowed to be arbitrary, or pickle protocol stuff, which is already written in target-independent ways, so it wouldn't reveal anything. Adding a record of carefully designed, known type and content to the pickle header would work for general machine characteristics, but it's easier just to add a field to RTPacking values, which are binary-encoded in 32 bits in the existing header, with bits to spare. Similarly, for lazy aligned objects (where each type can be different), it's easiest just to add a bit type descriptions, which are also binary encoded. Mika Nystrom wrote: > Hi Rodney, > > I am not sure if I am reading your email entirely correctly, but I > think so... you're trying to figure out things like offsets so the > Pickle runtime can re-build arbitrary data structures. > > When we were doing some concurrent programming in my group about ten > years ago, we were using a user-level threading system (very similar > but not identical to the old user-level threads in M3) and we needed > to figure out the location of the stack pointer in a C jmp_buf. > > We just wrote a program to do it... > > Could you do that? Write some arbitrary data whose bit pattern > you know to a field, cast it to char * (or some such), and search > for the bit pattern? Do it over and over with random data, and there > you go... > > Mika > -- ------------------------------------------------------------- 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 Sun Feb 17 19:03:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 19:03:17 +0100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> I'd rather not go this way and change the complete syntax and convert to and fro between the two. If we really want to do that, I'd rather have it as something like a compatible extension (as far as possible). What about changing only the keywords from uppercase to lowercase and using {} instead of BEGIN END? I'm not sure if that would satisfy the C-adherents, and I'm also not sure if it would introduce syntactic ambiguities, as {} are also used for sets. I'd like to keep the changes to the syntactical structure minimal (upper- and lowercase is only lexical matter after all). The abstract syntax should be kept as it is. If something like this would be possible, I'd vote for supporting both syntaxes in one compiler and turn on the C-style by a comment or automatically by recognizing the first word of a module. I'd not support mixing of styles within one module. Olaf PS: I'm not really suggesting we do this now, I just wanted to comment on the possibility of doing something like this. Anyway it will depend on somebody who provides appropriate patches and updates the language specification etc. Quoting Mika Nystrom : > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; > > And arrays? > > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; > > ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; > > I prefer Algol syntax myself but I could definitely see that there > might be people who would prefer a syntax mapped to C. One might > be able to sneak Modula-3 into places where it wouldn't otherwise > be used... > > Would it be possible to make "m3c" close enough in syntax that some > simple C header files could be processed? Am I just being ridiculous > now? A compiler that can process both C and Modula-3 in the same > file? > > Python, by the way, provides some interesting hooks for C programs > to interact with the Python garbage collector. Something similar > could be done here. (But there is far less reason to write C code > to plug into M3 than there is to write it to plug into Python.) > > Mika > > > Darko writes: >> If you like the idea, maybe you'd like join me in working out what >> such a syntax would look like? Note that I want to keep the structure >> the same, so no assignments in expressions, for example. Also, would C >> programmers revolt at not having post and pre increment, also inside >> expressions (as statements would be ok)? Requiring some sort of EVAL >> statement? I guess the big question is whether removing these things >> would make the whole idea unacceptable to the target audience. Does >> the Algol syntax serve a purpose in making it clear that it isn't C? >> >> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >> >>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>> can figure out how to turn Algol[Modula] back into C using <...>"... >>> >>> If you think it would help acceptance of Modula-3, I don't see why >>> not? >>> >>> I copied the code exactly the way it came off the old half-inch >>> tape from Berkeley. >>> >>> Darko writes: >>>> I'm not sure what you're getting at or if I'm missing something >>>> witty. >>>> I've said the form of the keywords makes little or no difference in >>>> my >>>> opinion. In my mail you quote I say there should be a C like syntax >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>>> matter of taste. I write in both all the time and it doesn't have any >>>> impact on me, I go almost entirely by indentation, which I think is >>>> very important. The indentation is pretty awful in code you posted >>>> but >>>> it could me my mailer. >>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>> ... > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Feb 17 19:11:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 13:11:39 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Not to rain on this parade, but I hate the idea of Swiss-Army-knife programs that do a multitude of tasks. Better to have a program do one thing well (and correctly) than many things badly (incorrectly). So the notion of one compiler handling two syntaxes does not sit well with me. Why not just a preprocessor from C-like syntax, which observes Modula-3 typing and semantics, into regular Modula-3? But, I echo Olaf's point -- there are way more important things to be worrying about than the color of the ceiling tiles, or in this case syntactic sugar. On Feb 17, 2008, at 1:03 PM, Olaf Wagner wrote: > I'd rather not go this way and change the complete syntax and > convert to and fro between the two. If we really want to do that, > I'd rather have it as something like a compatible extension (as far > as possible). > > What about changing only the keywords from uppercase to lowercase > and using {} instead of BEGIN END? I'm not sure if that would > satisfy the C-adherents, and I'm also not sure if it would > introduce syntactic ambiguities, as {} are also used for sets. > I'd like to keep the changes to the syntactical structure minimal > (upper- and lowercase is only lexical matter after all). The abstract > syntax should be kept as it is. > > If something like this would be possible, I'd vote for supporting > both syntaxes in one compiler and turn on the C-style by a comment > or automatically by recognizing the first word of a module. I'd not > support mixing of styles within one module. > > Olaf > > PS: I'm not really suggesting we do this now, I just wanted to comment > on the possibility of doing something like this. Anyway it will > depend on somebody who provides appropriate patches and updates > the language specification etc. > > Quoting Mika Nystrom : > >> Well I used to be mostly a C programmer but I long since weaned >> myself off that syntax :) >> >> Your point of the post- and pre-increment might be a bit difficult >> for C programmers to stomach, but... well it is probably hard to >> tell what programmers will hate and what they will love. >> >> Wouldn't a way to go about it be to take the Modula-3 BNF and modify >> the rules as needed? Would you like to be able to convert back and >> forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case >> all the keywords, convert the braces appropriately (a bit tricky >> since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO >> BEGIN END, so braces map only to the ENDs, not BEGINs (for the most >> part)). >> >> Type "attributes"(is that the right word?) are also an area where >> Modula-3 is significantly different from the C family. In C, you >> write >> >> int *a, *b, c; >> >> we have >> >> REF INTEGER a, b; >> INTEGER c; >> >> And arrays? >> >> VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF >> ARecord; >> >> ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; >> >> I prefer Algol syntax myself but I could definitely see that there >> might be people who would prefer a syntax mapped to C. One might >> be able to sneak Modula-3 into places where it wouldn't otherwise >> be used... >> >> Would it be possible to make "m3c" close enough in syntax that some >> simple C header files could be processed? Am I just being ridiculous >> now? A compiler that can process both C and Modula-3 in the same >> file? >> >> Python, by the way, provides some interesting hooks for C programs >> to interact with the Python garbage collector. Something similar >> could be done here. (But there is far less reason to write C code >> to plug into M3 than there is to write it to plug into Python.) >> >> Mika >> >> >> Darko writes: >>> If you like the idea, maybe you'd like join me in working out what >>> such a syntax would look like? Note that I want to keep the >>> structure >>> the same, so no assignments in expressions, for example. Also, >>> would C >>> programmers revolt at not having post and pre increment, also inside >>> expressions (as statements would be ok)? Requiring some sort of EVAL >>> statement? I guess the big question is whether removing these things >>> would make the whole idea unacceptable to the target audience. Does >>> the Algol syntax serve a purpose in making it clear that it isn't C? >>> >>> >>> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >>> >>>> >>>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>>> can figure out how to turn Algol[Modula] back into C using >>>> <...>"... >>>> >>>> If you think it would help acceptance of Modula-3, I don't see why >>>> not? >>>> >>>> I copied the code exactly the way it came off the old half-inch >>>> tape from Berkeley. >>>> >>>> Darko writes: >>>>> I'm not sure what you're getting at or if I'm missing something >>>>> witty. >>>>> I've said the form of the keywords makes little or no >>>>> difference in >>>>> my >>>>> opinion. In my mail you quote I say there should be a C like >>>>> syntax >>>>> for M3 as well as the existing one. I wasn't being sarcastic. >>>>> It's a >>>>> matter of taste. I write in both all the time and it doesn't >>>>> have any >>>>> impact on me, I go almost entirely by indentation, which I >>>>> think is >>>>> very important. The indentation is pretty awful in code you posted >>>>> but >>>>> it could me my mailer. >>>>> >>>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>>> ... >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Sun Feb 17 19:58:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 13:58:41 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: <20080217185841.GA27354@topoi.pooq.com> On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. Even with a preprocessor from C-style syntax to Modula 3, there would have to be some mechanism inserted into the Modula 3 compiler to recognise the original line numbers for error messages and debuggers and the like. Doing it this way might also make it possible to unify the Eiffel and Modula 3 communities ... though tere are possible better ways to accomplish this. I've always thought there's a lot of duplication of effort in their run-time systems. -- hendrik From lemming at henning-thielemann.de Sun Feb 17 21:27:47 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:27:47 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: On Sun, 17 Feb 2008, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. I see no need for Modula-3 with C syntax. I thought Java was created for this purpose. I collected a long list of C flaws, many of them are due to C syntax. From lemming at henning-thielemann.de Sun Feb 17 21:39:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:39:04 +0100 (MET) Subject: [M3devel] multiple inheritance In-Reply-To: <20080217131659.GA25696@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> <20080217131659.GA25696@topoi.pooq.com> Message-ID: On Sun, 17 Feb 2008 hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > > > [...many other good comments deleted...] > > > > > > >Multiple inheritance was left out of the language after long > > >discussions because it was not really understood at that time. > > >It may be that things have changed in this respect, but I still > > >don't think it is. Without knowing details I have heard that Eiffel has a satisfying implementation of multiple inheritance. However, since programming in Haskell I'm no longer missing traditional object oriented typing at all. From mika at async.caltech.edu Sun Feb 17 22:30:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 13:30:50 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sun, 17 Feb 2008 13:58:41 EST." <20080217185841.GA27354@topoi.pooq.com> Message-ID: <200802172130.m1HLUoMd000557@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: >> Not to rain on this parade, but I hate the idea of Swiss-Army-knife >> programs that do a multitude of tasks. Better to have a program do >> one thing well (and correctly) than many things badly (incorrectly). >> So the notion of one compiler handling two syntaxes does not sit well >> with me. Why not just a preprocessor from C-like syntax, which >> observes Modula-3 typing and semantics, into regular Modula-3? But, >> I echo Olaf's point -- there are way more important things to be >> worrying about than the color of the ceiling tiles, or in this case >> syntactic sugar. > >Even with a preprocessor from C-style syntax to Modula 3, there would >have to be some mechanism inserted into the Modula 3 compiler to >recognise the original line numbers for error messages and debuggers and >the like. > >Doing it this way might also make it possible to unify the Eiffel and >Modula 3 communities ... though tere are possible better ways to >accomplish this. I've always thought there's a lot of duplication of >effort in their run-time systems. > >-- hendrik I agree entirely with Tony's comments. I think a preprocessor (two preprocessors M3-2-MC and MC-2-M3) would be the way to do it, and I really don't mind Algol syntax. But I can see the argument that it might really do something for "marketing". I believe the compiler already permits <* LINE *> pragmas?? I think I saw it in the caltech-parser? Also if you want to merge forces with another project, wouldn't a good way be to do as in Stallman's nightmares, and start by "selling" the compiler back ends to other languages? Mika From jayk123 at hotmail.com Mon Feb 18 05:03:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:03:23 +0000 Subject: [M3devel] instructions for how to bring up a working NT386GNU toolset today Message-ID: This email has whitespace at the start/end of most lines in an attempt to preserve its formating. I already had cm3cg, and it is slow to rebuild. These instructions omit building that, but it is just build and ship in m3-sys\m3cc. Building m3cc does require a fair bit of Cygwin installed. Including but not limited to gcc, binutils, sed, make, awk. copy \cm3\bin\cm3cg.exe C:\cm3-min-WIN32-NT386-5.1.8\bin rmdir /q/s \cm3 xcopy /fivery C:\cm3-min-WIN32-NT386-5.1.8 c:\cm3 Older than 5.1.8 will not work. Setup a cm3/NT386 build environment, for example: set CM3_GCC_BACKEND=no set CM3_INSTALL=c:\cm3 set CM3_OSTYPE=WIN32 set CM3_ROOT=c:\dev2\cm3.2 set CM3_TARGET=NT386 set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 Almost none of these are needed, as they are probed for quite successfully. However this is what I am testing right now. Make sure Cygwin link.exe is not in %PATH%. I just delete it. del \cygwin\bin\link.exe I do actually have Cygwin always on my path, so there might be hidden dependencies on that. type \AUTOEXEC.BAT set CVS_RSH=ssh PATH %SystemDrive%\cygwin\bin;%PATH% There are also presently problems with slashes, such that managing M3CONFIG manually is a good idea for now. cd /d %cm3_root%\scripts\python .\do-cm3-all.py realclean .\upgrade.py In another cmd window, setup a CM3/NT386GNU environment, for example: set CM3_GCC_BACKEND=yes set CM3_INSTALL=/cm3 set CM3_OSTYPE=POSIX set CM3_ROOT=/dev2/cm3.2 set CM3_TARGET=NT386 set M3CONFIG=/dev2/cm3.2/m3-sys/cminstall/src/config/NT386GNU set OMIT_GCC=yes Again, this is largely redundant, but ok. What is most important is that CM3_OSTYPE=POSIX or that Cygwin uname is in the path. (Work is needed to cleanup this area that I have muddied over the past few months, including teaching cm3 that forward slashes work on Win32, except that won't help bootstrapping from 5.1.8) Also NOTE that I have symlinks setup for these paths to be correct: ls -l / lrwxrwxrwx 1 Jay None 11 Feb 10 01:10 c -> /cygdrive/c lrwxrwxrwx 1 Jay None 6 Feb 10 21:39 cm3 -> /c/cm3 lrwxrwxrwx 1 Jay None 7 Feb 10 01:10 dev2 -> /c/dev2 /cygdrive is long and ugly. .\do-cm3-all.py realclean Back in the NT386 environment: Point at the NT386GNU configuration file: set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386GNU Build the minimum NT386GNU system using the NT386 host compiler: .\bootntgnu.py and then restore the configuration to "normal": set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 (Yeah yeah, to clean step should work here.) Back in the NT386GNU environment: .\install-cm3-compiler.py .\upgrade.py Done. Next step is to try make-dist.py. (It doesn't work.) Also note that do-cm3-std gets much further than these steps. But these are just to start and get your own "min" system. A crash in m3bundle needs investigation if is still happens. Lots of GUI stuff does build but I haven't tried running it yet. Also NOTE that the integrated backend should be viable for targeting the Cygwin runtime, and this will build MUCH faster. Of course, you must have current source for this to work. I have not yet run the tests, sorry Olaf. Anyone want to try this and report back how it goes? Please? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx From hosking at cs.purdue.edu Mon Feb 18 05:16:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 23:16:06 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> Message-ID: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Solaris does not have %s for date -- we need an alternative for that usage in tinderbox-build.sh. On Feb 17, 2008, at 12:39 PM, Olaf Wagner wrote: > It's now more than two weeks since I asked for participants, and > none but the elego tests have shown up in the tinderbox since then. > So I think it may be time for a reminder :-) > > I don't want to hurry anyone, but if anything does not work as > expected or described or someone needs help getting tinderbox > reports transfered, don't hesitate to contact me. I'd really love to > see more platforms than FreeBSD and Linux and the occasional DARWIN > tested on a regular basis. > > Olaf > > PS: No need to apologize for anyone who maybe hasn't found the time > yet > to setup the test runs. I really understand that there are many > more > important matters. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >>> o I think we have agreed on the fact that automatic regression >>> testing >>> would help and should be introduced. Tests should be run daily/ >>> nightly >>> on as many platforms as possible, and results should be collected >>> and made available via WWW (elego offers to host these >>> services, as >>> it does for CVS repositories and CM3 web access). >> >> As you've surely all seen in the Status section of >> >> http://modula3.elegosoft.com/cm3/ >> >> the Elego Tinderbox regression test framework for CM3 has now been >> working for about two weeks. Though it's still not as complete and >> stable as I'd like it to be, I think it is now the right time for >> others >> to join the test framework and run the prepared tests in regular >> intervals on their favourite platforms. The results can now be >> transfered >> to Elego via your ssh account you also use for repository commits. >> >> Currently the tests are running on a Debian Linux system and a >> FreeBSD 6 >> system at Elego, and now and then I'm starting a run on my MacOS X >> laptop. The latter is not ideal for this purpose though. >> >> I'm now looking for other who would be willing to setup nightly tests >> on their own servers. The following systems are of interest >> >> o PPC_DARWIN on MacOS X 10.4 or 10.5 >> o I386_DARWIN >> o SOLgnu on any Solaris version >> o SOLsun " >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten >> some variants?) >> o NT386* on Windows 2000/XP/Vista >> o NetBSD2_i386 >> o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) >> o PPC_LINUX (though this seems to be broken for some time) >> o ALPHA_OSF -- is anybody still using Alphas? >> >> I think the other targets are more or less unused, but would of >> course not >> object to test results for them. >> >> There's a short description by Kaspar Schleiser of how to >> participate in >> cm3/scripts/regression/README. Basically you need to checkout the >> scripts, install 5.4.0 manually once, and setup a cron job. >> >> We're mostly interested in the results of `tinderbox-build.sh >> cm3.build', >> which is the complete bootstrap and release build based on 5.4.0, >> as I think the lastok build need not run on all platforms. It's >> mainly >> there to detect incompatible changes. >> >> The release build includes the package and m3tests tests. >> >> If you want to participate, I'd suggest to setup everything and run >> it once without transferring your results, then enable the transfer >> in cm3.build: >> >> tinderbox_mailer() { >> true # needed if function is emtpy without this... >> # to report to the elego tinderbox host, check README and >> uncomment this: >> # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox >> /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" >> } >> >> That's all. Please let me know in advance if you setup the tests, >> >> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Mon Feb 18 05:26:17 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:26:17 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3. Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal. Compatibility with headers is problematic but very useful. This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language. It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > I'd rather not go this way and change the complete syntax and> convert to and fro between the two. If we really want to do that,> I'd rather have it as something like a compatible extension (as far> as possible).> > What about changing only the keywords from uppercase to lowercase> and using {} instead of BEGIN END? I'm not sure if that would> satisfy the C-adherents, and I'm also not sure if it would> introduce syntactic ambiguities, as {} are also used for sets.> I'd like to keep the changes to the syntactical structure minimal> (upper- and lowercase is only lexical matter after all). The abstract> syntax should be kept as it is.> > If something like this would be possible, I'd vote for supporting> both syntaxes in one compiler and turn on the C-style by a comment> or automatically by recognizing the first word of a module. I'd not> support mixing of styles within one module.> > Olaf> > PS: I'm not really suggesting we do this now, I just wanted to comment> on the possibility of doing something like this. Anyway it will> depend on somebody who provides appropriate patches and updates> the language specification etc.> > Quoting Mika Nystrom :> > > Well I used to be mostly a C programmer but I long since weaned> > myself off that syntax :)> >> > Your point of the post- and pre-increment might be a bit difficult> > for C programmers to stomach, but... well it is probably hard to> > tell what programmers will hate and what they will love.> >> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify> > the rules as needed? Would you like to be able to convert back and> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case> > all the keywords, convert the braces appropriately (a bit tricky> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most> > part)).> >> > Type "attributes"(is that the right word?) are also an area where> > Modula-3 is significantly different from the C family. In C, you> > write> >> > int *a, *b, c;> >> > we have> >> > REF INTEGER a, b;> > INTEGER c;> >> > And arrays?> >> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;> >> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];> >> > I prefer Algol syntax myself but I could definitely see that there> > might be people who would prefer a syntax mapped to C. One might> > be able to sneak Modula-3 into places where it wouldn't otherwise> > be used...> >> > Would it be possible to make "m3c" close enough in syntax that some> > simple C header files could be processed? Am I just being ridiculous> > now? A compiler that can process both C and Modula-3 in the same> > file?> >> > Python, by the way, provides some interesting hooks for C programs> > to interact with the Python garbage collector. Something similar> > could be done here. (But there is far less reason to write C code> > to plug into M3 than there is to write it to plug into Python.)> >> > Mika> >> >> > Darko writes:> >> If you like the idea, maybe you'd like join me in working out what> >> such a syntax would look like? Note that I want to keep the structure> >> the same, so no assignments in expressions, for example. Also, would C> >> programmers revolt at not having post and pre increment, also inside> >> expressions (as statements would be ok)? Requiring some sort of EVAL> >> statement? I guess the big question is whether removing these things> >> would make the whole idea unacceptable to the target audience. Does> >> the Algol syntax serve a purpose in making it clear that it isn't C?> >>> >>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:> >>> >>>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you> >>> can figure out how to turn Algol[Modula] back into C using <...>"...> >>>> >>> If you think it would help acceptance of Modula-3, I don't see why> >>> not?> >>>> >>> I copied the code exactly the way it came off the old half-inch> >>> tape from Berkeley.> >>>> >>> Darko writes:> >>>> I'm not sure what you're getting at or if I'm missing something> >>>> witty.> >>>> I've said the form of the keywords makes little or no difference in> >>>> my> >>>> opinion. In my mail you quote I say there should be a C like syntax> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a> >>>> matter of taste. I write in both all the time and it doesn't have any> >>>> impact on me, I go almost entirely by indentation, which I think is> >>>> very important. The indentation is pretty awful in code you posted> >>>> but> >>>> it could me my mailer.> >>>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:> >>> ...> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 18 05:41:29 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 20:41:29 -0800 Subject: [M3devel] code submission Message-ID: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> Hello everyone, I was looking at some code I've written and realized that I have a very small piece of tested code that may be of interest to other Modula-3 users. It's a generic "trie" that I coded a few years ago. Does anyone have an opinion on adding it to cm3? Where, if so? http://www.async.caltech.edu/~mika/trie/ It's useful for parsing; if you're parsing a language with longish keywords it is many times faster to use this structure and ARRAY OF CHAR than using the standard hash tables with TEXTs. (I developed it to parse an old "punch-card", i.e., 80-character fixed-width records, format for financial data.) Mika From wagner at elegosoft.com Mon Feb 18 08:32:39 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 08:32:39 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Message-ID: <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> Quoting Tony Hosking : > Solaris does not have %s for date -- we need an alternative for that > usage in tinderbox-build.sh. You mean as in date -u +'%Y-%m-%d-%H-%M-%S? It's used quite often: % grep -l date scripts/regression/*.sh scripts/regression/defs.sh scripts/regression/tinderbox-build.sh scripts/regression/tinderbox-status.sh scripts/regression/update_changelog.sh scripts/regression/update_m3tests.sh scripts/regression/update_pkg_status.sh scripts/regression/update_snapshot_status.sh Would it be possible, as a work-around, to install the GNU tools (date, sed, awk etc.)? I should have known something will fail on Solaris, because the standard command line utilities they ship are still bug-compatible to those from the 80s :-/ We've had lots of problems with them at one of our customers, too, and just installed openpkg as a stable environment. But I think GNU command line utilties should also be available as a Solaris package. If this is the only problem or if you cannot install an alternative environment, we'll have to do something about date. I'll make some tests later when I have access to a SPARC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 10:20:29 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 09:20:29 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Some corrections.. try to make braces work (with some alteration for C) >> for SETS Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "but" should say "punt" That is, this dialect of C that has some Modula-3 features, might have optional safety, or even garbage collection. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]Date: Mon, 18 Feb 2008 04:26:17 +0000 I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3.Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal.Compatibility with headers is problematic but very useful.This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language.It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > I'd rather not go this way and change the complete syntax and> convert to and fro between the two. If we really want to do that,> I'd rather have it as something like a compatible extension (as far> as possible).> > What about changing only the keywords from uppercase to lowercase> and using {} instead of BEGIN END? I'm not sure if that would> satisfy the C-adherents, and I'm also not sure if it would> introduce syntactic ambiguities, as {} are also used for sets.> I'd like to keep the changes to the syntactical structure minimal> (upper- and lowercase is only lexical matter after all). The abstract> syntax should be kept as it is.> > If something like this would be possible, I'd vote for supporting> both syntaxes in one compiler and turn on the C-style by a comment> or automatically by recognizing the first word of a module. I'd not> support mixing of styles within one module.> > Olaf> > PS: I'm not really suggesting we do this now, I just wanted to comment> on the possibility of doing something like this. Anyway it will> depend on somebody who provides appropriate patches and updates> the language specification etc.> > Quoting Mika Nystrom :> > > Well I used to be mostly a C programmer but I long since weaned> > myself off that syntax :)> >> > Your point of the post- and pre-increment might be a bit difficult> > for C programmers to stomach, but... well it is probably hard to> > tell what programmers will hate and what they will love.> >> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify> > the rules as needed? Would you like to be able to convert back and> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case> > all the keywords, convert the braces appropriately (a bit tricky> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most> > part)).> >> > Type "attributes"(is that the right word?) are also an area where> > Modula-3 is significantly different from the C family. In C, you> > write> >> > int *a, *b, c;> >> > we have> >> > REF INTEGER a, b;> > INTEGER c;> >> > And arrays?> >> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;> >> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];> >> > I prefer Algol syntax myself but I could definitely see that there> > might be people who would prefer a syntax mapped to C. One might> > be able to sneak Modula-3 into places where it wouldn't otherwise> > be used...> >> > Would it be possible to make "m3c" close enough in syntax that some> > simple C header files could be processed? Am I just being ridiculous> > now? A compiler that can process both C and Modula-3 in the same> > file?> >> > Python, by the way, provides some interesting hooks for C programs> > to interact with the Python garbage collector. Something similar> > could be done here. (But there is far less reason to write C code> > to plug into M3 than there is to write it to plug into Python.)> >> > Mika> >> >> > Darko writes:> >> If you like the idea, maybe you'd like join me in working out what> >> such a syntax would look like? Note that I want to keep the structure> >> the same, so no assignments in expressions, for example. Also, would C> >> programmers revolt at not having post and pre increment, also inside> >> expressions (as statements would be ok)? Requiring some sort of EVAL> >> statement? I guess the big question is whether removing these things> >> would make the whole idea unacceptable to the target audience. Does> >> the Algol syntax serve a purpose in making it clear that it isn't C?> >>> >>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:> >>> >>>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you> >>> can figure out how to turn Algol[Modula] back into C using <...>"...> >>>> >>> If you think it would help acceptance of Modula-3, I don't see why> >>> not?> >>>> >>> I copied the code exactly the way it came off the old half-inch> >>> tape from Berkeley.> >>>> >>> Darko writes:> >>>> I'm not sure what you're getting at or if I'm missing something> >>>> witty.> >>>> I've said the form of the keywords makes little or no difference in> >>>> my> >>>> opinion. In my mail you quote I say there should be a C like syntax> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a> >>>> matter of taste. I write in both all the time and it doesn't have any> >>>> impact on me, I go almost entirely by indentation, which I think is> >>>> very important. The indentation is pretty awful in code you posted> >>>> but> >>>> it could me my mailer.> >>>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:> >>> ...> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 18 11:34:34 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 11:34:34 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Message-ID: <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Quoting Tony Hosking : > Solaris does not have %s for date -- we need an alternative for that > usage in tinderbox-build.sh. You're probably talking about a different problem than I thought, at least % date -u +'%Y-%m-%d-%H-%M-%S' 2008-02-18-10-00-34 blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % type date date is hashed (/bin/date) blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % uname -a SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 seems to be working for me on Solaris. Ah, I've found it now: date +%s. Michael says it's not possible to do that with Sun's data. Openpkg for example comes with gdate, which understands the %s: % gdate "+%s" 1203329509 blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % type gdate gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) gdate is part of the GNU coreutils. You can find it at http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml http://www.sunfreeware.com/programlistsparc10.html#coreutils Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Mon Feb 18 12:45:25 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Mon, 18 Feb 2008 12:45:25 +0100 Subject: [M3devel] List test Message-ID: <20080218124525.ego4vs4x4ok0gkko@mail.elegosoft.com> Please ignore. -- 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 hosking at cs.purdue.edu Mon Feb 18 14:39:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 08:39:23 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> Message-ID: No, I mean date '+%s', which just gives a raw time-stamp. date -u +'% Y-%m-%d-%H-%M-%S works just fine. I don't manage this machine so I'd like to avoid installing non- standard tools (if only so they don't get tangled up in the regression testing which should be done on a "vanilla" platform). On Feb 18, 2008, at 2:32 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Solaris does not have %s for date -- we need an alternative for that >> usage in tinderbox-build.sh. > > You mean as in date -u +'%Y-%m-%d-%H-%M-%S? > > It's used quite often: > % grep -l date scripts/regression/*.sh > scripts/regression/defs.sh > scripts/regression/tinderbox-build.sh > scripts/regression/tinderbox-status.sh > scripts/regression/update_changelog.sh > scripts/regression/update_m3tests.sh > scripts/regression/update_pkg_status.sh > scripts/regression/update_snapshot_status.sh > > Would it be possible, as a work-around, to install the GNU tools > (date, sed, awk etc.)? > > I should have known something will fail on Solaris, because the > standard command line utilities they ship are still bug-compatible > to those from the 80s :-/ We've had lots of problems with them > at one of our customers, too, and just installed openpkg as a stable > environment. But I think GNU command line utilties should also > be available as a Solaris package. > > If this is the only problem or if you cannot install an alternative > environment, we'll have to do something about date. I'll make some > tests later when I have access to a SPARC. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 14:41:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 08:41:49 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Message-ID: Yeah, perhaps I should install gdate. On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Solaris does not have %s for date -- we need an alternative for that >> usage in tinderbox-build.sh. > > You're probably talking about a different problem than I thought, > at least > > % date -u +'%Y-%m-%d-%H-%M-%S' > 2008-02-18-10-00-34 > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % type date > date is hashed (/bin/date) > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % uname -a > SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 > > seems to be working for me on Solaris. > > Ah, I've found it now: date +%s. > Michael says it's not possible to do that with Sun's data. > Openpkg for example comes with gdate, which understands the %s: > > % gdate "+%s" > 1203329509 > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % type gdate > gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) > > gdate is part of the GNU coreutils. You can find it at > > http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml > > http://www.sunfreeware.com/programlistsparc10.html#coreutils > > Hope this helps, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 15:02:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 15:02:22 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Message-ID: <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> Quoting Tony Hosking : > Yeah, perhaps I should install gdate. Is that acceptable then, or would you prefer that we write a small program (in C or M3) which only prints the seconds since the start of the epoch for the sake of tinderbox? Olaf > On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> Solaris does not have %s for date -- we need an alternative for that >>> usage in tinderbox-build.sh. >> >> You're probably talking about a different problem than I thought, >> at least >> >> % date -u +'%Y-%m-%d-%H-%M-%S' >> 2008-02-18-10-00-34 >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % type date >> date is hashed (/bin/date) >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % uname -a >> SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 >> >> seems to be working for me on Solaris. >> >> Ah, I've found it now: date +%s. >> Michael says it's not possible to do that with Sun's data. >> Openpkg for example comes with gdate, which understands the %s: >> >> % gdate "+%s" >> 1203329509 >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % type gdate >> gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) >> >> gdate is part of the GNU coreutils. You can find it at >> >> http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml >> >> http://www.sunfreeware.com/programlistsparc10.html#coreutils >> >> Hope this helps, >> >> Olaf >> -- Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Feb 18 15:19:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 09:19:55 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> Message-ID: <2BF46AA7-9BCA-4FFC-AE59-76707FFCC037@cs.purdue.edu> Yes, acceptable. I'll install gdate. On Feb 18, 2008, at 9:02 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Yeah, perhaps I should install gdate. > > Is that acceptable then, or would you prefer that we write a > small program (in C or M3) which only prints the seconds since the > start of the epoch for the sake of tinderbox? > > Olaf > >> On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> Solaris does not have %s for date -- we need an alternative for >>>> that >>>> usage in tinderbox-build.sh. >>> >>> You're probably talking about a different problem than I thought, >>> at least >>> >>> % date -u +'%Y-%m-%d-%H-%M-%S' >>> 2008-02-18-10-00-34 >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % type date >>> date is hashed (/bin/date) >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % uname -a >>> SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 >>> >>> seems to be working for me on Solaris. >>> >>> Ah, I've found it now: date +%s. >>> Michael says it's not possible to do that with Sun's data. >>> Openpkg for example comes with gdate, which understands the %s: >>> >>> % gdate "+%s" >>> 1203329509 >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % type gdate >>> gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) >>> >>> gdate is part of the GNU coreutils. You can find it at >>> >>> http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml >>> >>> http://www.sunfreeware.com/programlistsparc10.html#coreutils >>> >>> Hope this helps, >>> >>> Olaf >>> -- Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Mon Feb 18 16:56:20 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 18 Feb 2008 10:56:20 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B60CE0.8050506@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> Message-ID: <47B9644F.1E75.00D7.1@scires.com> I use pickles extensively and they are used also by network objects. I've never used LAZYALIGN. My vote is that we don't break something (pickles/netobj) to add support for something that is rarely used. Regards, Randy >>> "Rodney M. Bates" 2/15/2008 5:06 PM >>> I'll put it in comments in the code. I am sure I can fix it to handle LAZYALIGN too, just not sure whether I can do it without requiring existing pickle files to be regenerated and/or existing code that reads/writes pickles to need recompilation. Anybody on this list who has code that might be affected if pickles or compiled code were invalidated by a change? I do propose we change the way of telling the compiler to do LAZYALIGN so that it is a property of a type and affects all variables of that type. Olaf Wagner wrote: > Perhaps we should check-in this description somewhere near the > actual code? Or is there enough documentation already? > > Olaf > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > Or at least put a big sticker on that it will break pickles. > > Quoting "Rodney M. Bates" : > >> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >> etc. only works for getting object layouts as on the machine executing >> the code, which is all that is needed when writing a pickle. >> >> When reading, Pickle code needs to know the layouts of a type both as >> it is on the reading machine and as it was on the machine that wrote >> the pickle. The type description that the compiler generates is >> excerpted and contains no field displacements, just lists of field >> types (which are either recursive type descriptions or builtin types). >> So it is independent of word sizes, etc. >> >> Pickles regenerates the displacements using the few target machine >> characteristics in a RTPacking.T It traverses a type description and >> simultaneously computes two sets of field displacements, both as they >> are on the reading machine and on the writing machine. For the latter, >> the value of RTPacking.T is (after a compact bit encoding) stored in the >> header of the pickle file. For the former, it's gotten by techniques >> like >> using BITSIZE. This is actually all done in RTTipe, part of m3core, and >> called by Pickle code. >> >> This is very fragile. RTTipe has to duplicate the compiler's layout >> behavior. There is no shared code. Making it common would involve >> quite a bit of rework, as the two use substantially different data >> structure and code organization. It will be obvious what kind of bit >> damage could occur if the two algorithms didn't agree. >> >> This is why I am obsessing over LAZYALIGN. I have been comparing the >> field displacement computations in RTTipe and in the compiler. The >> former is oblivious to LAZYALIGN. >> >> Note that all this is required even without any packing of small fields >> within words. E.G., a record with two INTEGER fields, pickled on a >> 32-bit machine and unpickled on a 64. >> >> Tony Hosking wrote: >> >>> Rodney, >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> would have thought all packing is done on word-sized units anyway. >>> Each side of the connection can check BITSIZE(LONGINT) to figure >>> out what to do presumably no differently from the way INTEGER is >>> communicated between 32-bit and 64-bit machines. Am I missing >>> something? >>> >>> -- Tony >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> (which can vary independently of the size of INTEGER). >>>>> 2) Variable length values of subrange bounds found in type >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> what the native word size can represent. >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>>> is not handled by Pickles. >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> >>> >> >> -- >> ------------------------------------------------------------- >> 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 > > > > -- ------------------------------------------------------------- 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 Mon Feb 18 18:36:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 12:36:43 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B9644F.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> Message-ID: <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Can someone remind me again why we need LAZYALIGN? I concur with Randy that if it is rarely used and moreso breaks things I would argue to abandon it. On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add > support for something that is rarely used. > Regards, > Randy > > >>> "Rodney M. Bates" 2/15/2008 5:06 PM >>> > I'll put it in comments in the code. I am sure I can fix it to > handle LAZYALIGN too, just not sure whether I can do it without > requiring existing pickle files to be regenerated and/or existing > code that reads/writes pickles to need recompilation. > > Anybody on this list who has code that might be affected if pickles > or compiled code were invalidated by a change? > > I do propose we change the way of telling the compiler to do > LAZYALIGN so that it is a property of a type and affects all > variables of that type. > > Olaf Wagner wrote: > > Perhaps we should check-in this description somewhere near the > > actual code? Or is there enough documentation already? > > > > Olaf > > > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > > Or at least put a big sticker on that it will break pickles. > > > > Quoting "Rodney M. Bates" : > > > >> The word "Packing" in RTPacking is perhaps misleading. Using > BITSIZE, > >> etc. only works for getting object layouts as on the machine > executing > >> the code, which is all that is needed when writing a pickle. > >> > >> When reading, Pickle code needs to know the layouts of a type > both as > >> it is on the reading machine and as it was on the machine that > wrote > >> the pickle. The type description that the compiler generates is > >> excerpted and contains no field displacements, just lists of field > >> types (which are either recursive type descriptions or builtin > types). > >> So it is independent of word sizes, etc. > >> > >> Pickles regenerates the displacements using the few target machine > >> characteristics in a RTPacking.T It traverses a type > description and > >> simultaneously computes two sets of field displacements, both as > they > >> are on the reading machine and on the writing machine. For the > latter, > >> the value of RTPacking.T is (after a compact bit encoding) > stored in the > >> header of the pickle file. For the former, it's gotten by > techniques > >> like > >> using BITSIZE. This is actually all done in RTTipe, part of > m3core, and > >> called by Pickle code. > >> > >> This is very fragile. RTTipe has to duplicate the compiler's > layout > >> behavior. There is no shared code. Making it common would involve > >> quite a bit of rework, as the two use substantially different data > >> structure and code organization. It will be obvious what kind > of bit > >> damage could occur if the two algorithms didn't agree. > >> > >> This is why I am obsessing over LAZYALIGN. I have been > comparing the > >> field displacement computations in RTTipe and in the compiler. The > >> former is oblivious to LAZYALIGN. > >> > >> Note that all this is required even without any packing of small > fields > >> within words. E.G., a record with two INTEGER fields, pickled on a > >> 32-bit machine and unpickled on a 64. > >> > >> Tony Hosking wrote: > >> > >>> Rodney, > >>> > >>> Why does there need to be an entry for LONGINT in RTPacking? I > >>> would have thought all packing is done on word-sized units > anyway. > >>> Each side of the connection can check BITSIZE(LONGINT) to figure > >>> out what to do presumably no differently from the way INTEGER is > >>> communicated between 32-bit and 64-bit machines. Am I missing > >>> something? > >>> > >>> -- Tony > >>> > >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >>> > >>>> Ah, OK. I don't much delve in pickle-land. Anything I can > help with? > >>>> > >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >>>> > >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, > >>>>> (which can vary independently of the size of INTEGER). > >>>>> 2) Variable length values of subrange bounds found in type > >>>>> descriptions (in TipeDesc.i3) can now have values beyond > >>>>> what the native word size can represent. > >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added > recently) > >>>>> is not handled by Pickles. > >>>>> > >>>>> I have done some coding on this, but have been interrupted. > >>>>> > >>>>> Tony Hosking wrote: > >>>>> > >>>>>> Why is LONGINT for pickles not yet supported? > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> ------------------------------------------------------------- > >>>>> 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 > >>> > >>> > >>> > >>> > >> > >> -- > >> ------------------------------------------------------------- > >> 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 > > > > > > > > > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Mon Feb 18 19:55:53 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 10:55:53 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 18 Feb 2008 16:16:44." <20080218151644.E5E4410D4331@birch.elegosoft.com> Message-ID: <200802181855.m1IItr0w032707@camembert.async.caltech.edu> Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 08/02/18 16:16:44 > >Modified files: > cm3/m3-sys/m3quake/src/: QMachine.i3 QMachine.m3 > cm3/m3-sys/cm3/src/: M3Path.m3 > >Log message: > At least for purposes of determining if Join(a,b) is b or a + slash + b, > treat any path that starts with a forward or backward slash, or > contains a colon as the second character, as absolute, on all platforms. > It is ASSUMED that backslashes and colons are never used in paths > on non-Windows systems, or at least that this interpretation is ok. I think people are careful not to use backslashes on Unix because it does weird things in the shell, so "it's not surprising" if things go bad if you use backslashes in your filenames. I know I never have, on purpose. But colons? Colons are not special in any way, shape, or form, on Unix... I think "it is extremely surprising" to a Unix user if a path with a colon in it breaks something. Mika From wagner at elegosoft.com Mon Feb 18 20:35:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 20:35:36 +0100 Subject: [M3devel] code submission In-Reply-To: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> References: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> Message-ID: <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> Quoting Mika Nystrom : > Hello everyone, > > I was looking at some code I've written and realized that I have a > very small piece of tested code that may be of interest to other > Modula-3 users. It's a generic "trie" that I coded a few years > ago. Does anyone have an opinion on adding it to cm3? Where, if so? > > http://www.async.caltech.edu/~mika/trie/ > > It's useful for parsing; if you're parsing a language with longish > keywords it is many times faster to use this structure and ARRAY > OF CHAR than using the standard hash tables with TEXTs. (I developed > it to parse an old "punch-card", i.e., 80-character fixed-width > records, format for financial data.) Of course we could add this as a small package to m3-libs, or even to libm3 (it looks rather small). I hate to sound so uneducated, but what exactly does `trie' stand for? It's not contained in my favourite online dictionary either. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 20:37:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 19:37:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802181855.m1IItr0w032707@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 16:16:44." <20080218151644.E5E4410D4331@birch.elegosoft.com> <200802181855.m1IItr0w032707@camembert.async.caltech.edu> Message-ID: > But colons? Colons are not special in any way, shape, or form, on> Unix... I think "it is extremely surprising" to a Unix user if a path Ever try putting a path with a colon into $PATH? Does it work? Or copying a file with a colon in its name to a Windows system? Does it work? This part could be limited to systems that have $OS == Windows_NT I guess. As a user switching between multiple systems, this area is quite frustrating...I guess no matter what. Sometimes one form works, sometimes another, sometimes either, often with identical meaning, but not always. These changes, and about one more, should make building NT386GNU a fair amount easier.. Currently it is any path with a colon in the second character. How about if that is further restricted to having a-z in the first character and/or more importantly a slash in the third character? - Jay > To: jkrell at elego.de> Date: Mon, 18 Feb 2008 10:55:53 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay Krell writes:> >CVSROOT: /usr/cvs> >Changes by: jkrell at birch. 08/02/18 16:16:44> >> >Modified files:> > cm3/m3-sys/m3quake/src/: QMachine.i3 QMachine.m3 > > cm3/m3-sys/cm3/src/: M3Path.m3 > >> >Log message:> > At least for purposes of determining if Join(a,b) is b or a + slash + b,> > treat any path that starts with a forward or backward slash, or> > contains a colon as the second character, as absolute, on all platforms.> > It is ASSUMED that backslashes and colons are never used in paths> > on non-Windows systems, or at least that this interpretation is ok.> > I think people are careful not to use backslashes on Unix because> it does weird things in the shell, so "it's not surprising" if> things go bad if you use backslashes in your filenames. I know I> never have, on purpose.> > But colons? Colons are not special in any way, shape, or form, on> Unix... I think "it is extremely surprising" to a Unix user if a path> with a colon in it breaks something. > > Mika _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 18 20:50:20 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 19:50:20 +0000 Subject: [M3devel] code submission In-Reply-To: <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> References: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> Message-ID: aka "prefix tree" if I want to recognize the strings, foo, food, fudge, and bar look at the first character if it is 'b', go ahead and compare to bar (or the tail to "ar") if it is 'f' look at the second character if it is 'u', go ahead and compare to "fudge" (or the tail to "dge") if it 'o' compare the third character and so on Whether or not the data "stops" at unique prefixes is an implementation detail. If it does, the leaves can contain the entire string or just the tail. I've fiddled with generating large nested switch statements from a list of strings. I noticed there are many optimizations you can make. Of course, first you check the length. Then, really, instead of progressing from left to right, you can pick out characters with a higher switching factor. For example if I have the strings foof and food, just look at the last character. As well a hash based algorithm is probably best. Precompute the hashes of all the strings. Sor them. Hash your input string. Binary search for the hash. And the compare for an exact match. If you are going to do the final compare anyway, then you are going to touch the whole string anyway, you might as well hash it and do a binary search I think. Make sure the hash function is fast of course, and not "perfect". - Jay > Date: Mon, 18 Feb 2008 20:35:36 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] code submission> > Quoting Mika Nystrom :> > > Hello everyone,> >> > I was looking at some code I've written and realized that I have a> > very small piece of tested code that may be of interest to other> > Modula-3 users. It's a generic "trie" that I coded a few years> > ago. Does anyone have an opinion on adding it to cm3? Where, if so?> >> > http://www.async.caltech.edu/~mika/trie/> >> > It's useful for parsing; if you're parsing a language with longish> > keywords it is many times faster to use this structure and ARRAY> > OF CHAR than using the standard hash tables with TEXTs. (I developed> > it to parse an old "punch-card", i.e., 80-character fixed-width> > records, format for financial data.)> > Of course we could add this as a small package to m3-libs, or> even to libm3 (it looks rather small).> > I hate to sound so uneducated, but what exactly does `trie' stand for?> It's not contained in my favourite online dictionary either.> > Olaf> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Feb 18 21:01:39 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 07:01:39 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: The alignment behaviour is absolutely crucial to programming natively in Mac OS X and should be kept. I have a great need for it. The PRGAMA is of no use and can be removed. Does anyone have any objections to making this alignment behaviour standard? On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > Can someone remind me again why we need LAZYALIGN? I concur with > Randy that if it is rarely used and moreso breaks things I would > argue to abandon it. > > On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > >> I use pickles extensively and they are used also by network objects. >> I've never used LAZYALIGN. >> My vote is that we don't break something (pickles/netobj) to add >> support for something that is rarely used. >> Regards, >> Randy >> >> >>> "Rodney M. Bates" 2/15/2008 5:06 PM >> >>> >> I'll put it in comments in the code. I am sure I can fix it to >> handle LAZYALIGN too, just not sure whether I can do it without >> requiring existing pickle files to be regenerated and/or existing >> code that reads/writes pickles to need recompilation. >> >> Anybody on this list who has code that might be affected if pickles >> or compiled code were invalidated by a change? >> >> I do propose we change the way of telling the compiler to do >> LAZYALIGN so that it is a property of a type and affects all >> variables of that type. >> >> Olaf Wagner wrote: >> > Perhaps we should check-in this description somewhere near the >> > actual code? Or is there enough documentation already? >> > >> > Olaf >> > >> > PS: Based on your description, I'd say we should abandon LAZYALIGN. >> > Or at least put a big sticker on that it will break pickles. >> > >> > Quoting "Rodney M. Bates" : >> > >> >> The word "Packing" in RTPacking is perhaps misleading. Using >> BITSIZE, >> >> etc. only works for getting object layouts as on the machine >> executing >> >> the code, which is all that is needed when writing a pickle. >> >> >> >> When reading, Pickle code needs to know the layouts of a type >> both as >> >> it is on the reading machine and as it was on the machine that >> wrote >> >> the pickle. The type description that the compiler generates is >> >> excerpted and contains no field displacements, just lists of field >> >> types (which are either recursive type descriptions or builtin >> types). >> >> So it is independent of word sizes, etc. >> >> >> >> Pickles regenerates the displacements using the few target machine >> >> characteristics in a RTPacking.T It traverses a type >> description and >> >> simultaneously computes two sets of field displacements, both as >> they >> >> are on the reading machine and on the writing machine. For the >> latter, >> >> the value of RTPacking.T is (after a compact bit encoding) >> stored in the >> >> header of the pickle file. For the former, it's gotten by >> techniques >> >> like >> >> using BITSIZE. This is actually all done in RTTipe, part of >> m3core, and >> >> called by Pickle code. >> >> >> >> This is very fragile. RTTipe has to duplicate the compiler's >> layout >> >> behavior. There is no shared code. Making it common would >> involve >> >> quite a bit of rework, as the two use substantially different data >> >> structure and code organization. It will be obvious what kind >> of bit >> >> damage could occur if the two algorithms didn't agree. >> >> >> >> This is why I am obsessing over LAZYALIGN. I have been >> comparing the >> >> field displacement computations in RTTipe and in the compiler. >> The >> >> former is oblivious to LAZYALIGN. >> >> >> >> Note that all this is required even without any packing of small >> fields >> >> within words. E.G., a record with two INTEGER fields, pickled >> on a >> >> 32-bit machine and unpickled on a 64. >> >> >> >> Tony Hosking wrote: >> >> >> >>> Rodney, >> >>> >> >>> Why does there need to be an entry for LONGINT in RTPacking? I >> >>> would have thought all packing is done on word-sized units >> anyway. >> >>> Each side of the connection can check BITSIZE(LONGINT) to >> figure >> >>> out what to do presumably no differently from the way INTEGER is >> >>> communicated between 32-bit and 64-bit machines. Am I missing >> >>> something? >> >>> >> >>> -- Tony >> >>> >> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> >> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >> help with? >> >>>> >> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >> >>>> >> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >> >>>>> (which can vary independently of the size of INTEGER). >> >>>>> 2) Variable length values of subrange bounds found in type >> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >> >>>>> what the native word size can represent. >> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >> recently) >> >>>>> is not handled by Pickles. >> >>>>> >> >>>>> I have done some coding on this, but have been interrupted. >> >>>>> >> >>>>> Tony Hosking wrote: >> >>>>> >> >>>>>> Why is LONGINT for pickles not yet supported? >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> ------------------------------------------------------------- >> >>>>> 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 >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> ------------------------------------------------------------- >> >> 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 >> > >> > >> > >> > >> >> -- >> ------------------------------------------------------------- >> 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 hosking at cs.purdue.edu Mon Feb 18 22:32:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 16:32:46 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: On Feb 18, 2008, at 3:01 PM, Darko wrote: > The alignment behaviour is absolutely crucial to programming > natively in Mac OS X and should be kept. I have a great need for it. > > The PRGAMA is of no use and can be removed. > > Does anyone have any objections to making this alignment behaviour > standard? What do you mean make LAZYALIGN standard? Why wouldn't we go with the standard gcc-backend alignment? Perhaps I don't understand what it is you are doing or trying to do. Again, please remind me what it is that LAZYALIGN does and why it is needed. > On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > >> Can someone remind me again why we need LAZYALIGN? I concur with >> Randy that if it is rarely used and moreso breaks things I would >> argue to abandon it. >> >> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >> >>> I use pickles extensively and they are used also by network objects. >>> I've never used LAZYALIGN. >>> My vote is that we don't break something (pickles/netobj) to add >>> support for something that is rarely used. >>> Regards, >>> Randy >>> >>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>> PM >>> >>> I'll put it in comments in the code. I am sure I can fix it to >>> handle LAZYALIGN too, just not sure whether I can do it without >>> requiring existing pickle files to be regenerated and/or existing >>> code that reads/writes pickles to need recompilation. >>> >>> Anybody on this list who has code that might be affected if pickles >>> or compiled code were invalidated by a change? >>> >>> I do propose we change the way of telling the compiler to do >>> LAZYALIGN so that it is a property of a type and affects all >>> variables of that type. >>> >>> Olaf Wagner wrote: >>> > Perhaps we should check-in this description somewhere near the >>> > actual code? Or is there enough documentation already? >>> > >>> > Olaf >>> > >>> > PS: Based on your description, I'd say we should abandon >>> LAZYALIGN. >>> > Or at least put a big sticker on that it will break pickles. >>> > >>> > Quoting "Rodney M. Bates" : >>> > >>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>> BITSIZE, >>> >> etc. only works for getting object layouts as on the machine >>> executing >>> >> the code, which is all that is needed when writing a pickle. >>> >> >>> >> When reading, Pickle code needs to know the layouts of a type >>> both as >>> >> it is on the reading machine and as it was on the machine that >>> wrote >>> >> the pickle. The type description that the compiler generates is >>> >> excerpted and contains no field displacements, just lists of >>> field >>> >> types (which are either recursive type descriptions or builtin >>> types). >>> >> So it is independent of word sizes, etc. >>> >> >>> >> Pickles regenerates the displacements using the few target >>> machine >>> >> characteristics in a RTPacking.T It traverses a type >>> description and >>> >> simultaneously computes two sets of field displacements, both >>> as they >>> >> are on the reading machine and on the writing machine. For >>> the latter, >>> >> the value of RTPacking.T is (after a compact bit encoding) >>> stored in the >>> >> header of the pickle file. For the former, it's gotten by >>> techniques >>> >> like >>> >> using BITSIZE. This is actually all done in RTTipe, part of >>> m3core, and >>> >> called by Pickle code. >>> >> >>> >> This is very fragile. RTTipe has to duplicate the compiler's >>> layout >>> >> behavior. There is no shared code. Making it common would >>> involve >>> >> quite a bit of rework, as the two use substantially different >>> data >>> >> structure and code organization. It will be obvious what kind >>> of bit >>> >> damage could occur if the two algorithms didn't agree. >>> >> >>> >> This is why I am obsessing over LAZYALIGN. I have been >>> comparing the >>> >> field displacement computations in RTTipe and in the >>> compiler. The >>> >> former is oblivious to LAZYALIGN. >>> >> >>> >> Note that all this is required even without any packing of >>> small fields >>> >> within words. E.G., a record with two INTEGER fields, pickled >>> on a >>> >> 32-bit machine and unpickled on a 64. >>> >> >>> >> Tony Hosking wrote: >>> >> >>> >>> Rodney, >>> >>> >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> >>> would have thought all packing is done on word-sized units >>> anyway. >>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>> figure >>> >>> out what to do presumably no differently from the way >>> INTEGER is >>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>> >>> something? >>> >>> >>> >>> -- Tony >>> >>> >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>> >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>> help with? >>> >>>> >>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> >>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>> >>>>> (which can vary independently of the size of INTEGER). >>> >>>>> 2) Variable length values of subrange bounds found in type >>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>> >>>>> what the native word size can represent. >>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>> recently) >>> >>>>> is not handled by Pickles. >>> >>>>> >>> >>>>> I have done some coding on this, but have been interrupted. >>> >>>>> >>> >>>>> Tony Hosking wrote: >>> >>>>> >>> >>>>>> Why is LONGINT for pickles not yet supported? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> ------------------------------------------------------------- >>> >>>>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >> -- >>> >> ------------------------------------------------------------- >>> >> 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 >>> > >>> > >>> > >>> > >>> >>> -- >>> ------------------------------------------------------------- >>> 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 mika at async.caltech.edu Mon Feb 18 23:04:06 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 14:04:06 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." Message-ID: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> I never tried putting it in my PATH, no... You are right, colons are *slightly* special. I am not in the habit of copying files to Windows. I only copy files between Unix and Windows to save them from Windows. That being said, I am pretty sure I use colons more in filenames than I use the letter "q". Could you ban the letter "q" instead? :) If you've gotta do it, then do it. It's just ... weird. I personally will probably never run into the issue. I use colons in filenames a lot, but as a separator for various types of data files. :. Is your code able to import (or duplicate...) Pathname? I would have thought that that interface has all the necessary bits to make paths portable... MIka Jay writes: >--_dfd4e29a-b904-43be-8435-4824d419d270_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> But colons? Colons are not special in any way, shape, or form, on> Unix..= >. I think "it is extremely surprising" to a Unix user if a path >Ever try putting a path with a colon into $PATH? Does it work? >Or copying a file with a colon in its name to a Windows system? Does it wor= >k? >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue= >ss. >=20 >As a user switching between multiple systems, this area is quite frustratin= >g...I guess no matter what. >Sometimes one form works, sometimes another, sometimes either, often with i= >dentical meaning, but not always. >These changes, and about one more, should make building NT386GNU a fair amo= >unt easier.. >=20 >Currently it is any path with a colon in the second character. >How about if that is further restricted to having a-z in the first characte= >r and/or more importantly a slash in the third character? >=20 > - Jay > > > From jayk123 at hotmail.com Mon Feb 18 23:27:56 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 22:27:56 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: I'm going to work on this more but not today. I will at least restrict it to check that the next character is a slash. I'm not sure that will satisfy folks. The Pathname module is/was being used but is a little unsatisfactory. > I use colons in filenames a lot Do you use it in source files? For "root" directories, like where your cm3 install/source is? I'm trying to think/wiggle through what might be an acceptable escape. Something like -- where files in general are vs. where "programmer" files are. Putting a colon in a filename really is quite non-portable. And that may or may not matter. The existing Modula-3 code was fairly strict and I very unsure it was right. I had a question drafted to m3devel that I ended up not sending. It went roughly like: " Has anyone done a cross build where host and target vary in naming conventions? I am skeptical that this works, and am strongly considering /slightly/ depending on that or making it "worse". In particular, there is provision in the code for "converting" between host and target paths, but all it does is translate slashes. It doesn't translate libfoo.a to foo.lib for example. " Upon further digging though, I decide that my more immediate severe problem could be dealt with not by making things worse but by making them better. This is the change around checking NAMING_CONVENTIONS earlier. While my analysis was not 100% thorough, it is my very strong suspicion that the NAMING_CONVENTION and undocumented TARGET_NAMING configuration variables never really worked. Sure, they affected the name of the .m3x file. But that is about it. I didn't check .exes, but probably didn't work, and what I was seeing was they didn't work for libraries. M3Path.m3 sets up one set of path data in three ways. variable initialization (VAR foo := 123) module initialization (BEGIN foo := 456 END Module.) and explicit calls after reading the config file The problem was that the explicit calls were very late, so the module initialization is what held. If Join(a,b) == a/b, then you'd get Unix naming conventions. /Arguably/ this is exactly correct. But I would like the slash and the "naming" to be separate, at least for now. That is, NT386GNU uses forward slashes but foo.lib instead of libfoo.a. I should try to change that actually. I had trouble changing it for this reason since I was cross building from NT386. The NT386 HOST wants to use Win32 naming conventions, "\" and foo.lib, even if the config file asks for Unix naming.. Anyway, this is all somewhat of a tangent, one in which I'm more confident of where to go and that what I changed is ok. (It might become irrelevant.) The other issues are around "difficulty" setting paths. I had CM3_ROOT=c:\dev2\cm3.2. That wouldn't necessarily work with NT386GNU. It seems darn near possible to have one path syntax and one set of code for dealing with it. But maybe not. Even semicolon vs. colon seems doable. Specifically, if an element of $PATH appears to be just a single character, that colon is not a $PATH divider. Perhaps I just need to have two sets of CM3_ROOT / CM3_INSTALL and perhaps M3CONFIG variables. I was kind of hoping not. It's worse than that really, since the two hosts can target the two targets, so host and target paths needs to be better distinguished than I believe the are now. I was saying there is code to change the slashes, but there isn't code to deal with a leading drive letter. What I have been particularly avoiding is calls out to cygwin_convert_path or such, but maybe that's what I need to do. Get ROOT / CM3_INSTALL etc. from the command line and environment, convert as appropriate, and move on. ROOT in particular is set by Python. Usually for me that is Win32 Python, but Cygwin Python is an option. So then Python has to know what cm3 it is running? I considered probing it with findstr /i /m cm3.exe cygwin1.dll. I considered something like cm3 -report_something_or_other, kind of like gcc has -print-gcc-lib-name or whatnot. These might still be viable ideas. Historically cross environments don't allow multiple "targets" / "platforms" / "configurations" / "whatever" to run on the same OS. But there is some of an opposite trend. Like how NT386 and NT386GNU run on the same OS. Like SOLsun, SOLgnu. Like x86 on AMD64 operating systems. So maybe a little bit of support is good there, the cm3 -print-slash or cm3 -print-host or something. Also I forgot to point out that Win32 is often find with forward slashes, but notable file.open dialogs are not. I very frequently copy compiler output to file.open dialogs so in some places backward slashes are preferred. A possible strategy is to sniff what the user is using -- such as in any of those environment variables -- and favor it. Or for each Join operating harvest a path separater from the parameters and default if there is none there. I have some code working like that last option right now but it's not quite working and has to wait. It is very reasonable to have Win32 treat forward and backward slashes as the same, in particular. It is fairly reasonable imho for Posix code to also treat them the same but "fixup" backward to forward. As well, on Windows, if you mostly limit yourself to one drive letter, then /foo/bar is a pretty acceptable form.. Anyway...lots of facts, some easy conclusions, some unclear conclusions. I'll fiddle around with it more later. Ideally switching between NT386 and NT386GNU is fairly easy.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 18 Feb 2008 14:04:06 -0800> From: mika at async.caltech.edu> > > I never tried putting it in my PATH, no... You are right, colons> are *slightly* special. I am not in the habit of copying files to> Windows. I only copy files between Unix and Windows to save them> from Windows.> > That being said, I am pretty sure I use colons more in filenames> than I use the letter "q". Could you ban the letter "q" instead? :)> > If you've gotta do it, then do it. It's just ... weird.> > I personally will probably never run into the issue. I use colons> in filenames a lot, but as a separator for various types of data> files. :.> > Is your code able to import (or duplicate...) Pathname? I would> have thought that that interface has all the necessary bits to make> paths portable...> > MIka> > Jay writes:> >--_dfd4e29a-b904-43be-8435-4824d419d270_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> But colons? Colons are not special in any way, shape, or form, on> Unix..=> >. I think "it is extremely surprising" to a Unix user if a path> >Ever try putting a path with a colon into $PATH? Does it work?> >Or copying a file with a colon in its name to a Windows system? Does it wor=> >k?> >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue=> >ss.> >=20> >As a user switching between multiple systems, this area is quite frustratin=> >g...I guess no matter what.> >Sometimes one form works, sometimes another, sometimes either, often with i=> >dentical meaning, but not always.> >These changes, and about one more, should make building NT386GNU a fair amo=> >unt easier..> >=20> >Currently it is any path with a colon in the second character.> >How about if that is further restricted to having a-z in the first characte=> >r and/or more importantly a slash in the third character?> >=20> > - Jay> >> >> > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Feb 19 02:44:02 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 02:44:02 +0100 (CET) Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> Message-ID: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Actually rather than compilain rather grumpily, maybe I can just make the changes required to RTTipe and do the work to reomve the pragma. I can work with Randy to ensure it doesn't break pickles, there is no reason why it should. On tha subject Randy, I assume pickles encode the number of BITS FOR for a field? If not it should. > We seem to be going through these same point several times. I'm not sure > what the difficulty is, I'm just repeating myself. > > Keep in mind this applies *only* to packed structures, ie BIT FOR or bit > fields. > > The change I put in libralised the *M3* alignment rules so that BITS FOR > fields in structures would align on byte boundries if possible instead of > restricting them to word alignment generally. GCC happily generates code > for this. There may be restrictions in GCC's C as to how you can arrange > bit fields but I don't see what they have to do with M3. > > This is absolutely essentail for using the native APIs on Mac OS X and its > removal would make M3 pointless for use on the Mac, at least more me. > > This should be the default behviour. If you are using BITS FOR it's > becuase you want to arrange the fields in a record in particular way. Why > then arbitrarliy pad out the fields? If performance is an issue, the user > should be using appropriate field bit sizes. The implementation rule for > BITS FOR in M3 is implementation dependent, there are no language issues. > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > created and had nothing to do with me. I diagreed with it and never used > it in the version of the compiler I ran. I support its removal. > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: >> >>> The alignment behaviour is absolutely crucial to programming >>> natively in Mac OS X and should be kept. I have a great need for it. >>> >>> The PRGAMA is of no use and can be removed. >>> >>> Does anyone have any objections to making this alignment behaviour >>> standard? >> >> What do you mean make LAZYALIGN standard? Why wouldn't we go with >> the standard gcc-backend alignment? Perhaps I don't understand what >> it is you are doing or trying to do. Again, please remind me what it >> is that LAZYALIGN does and why it is needed. >> >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>> >>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>> Randy that if it is rarely used and moreso breaks things I would >>>> argue to abandon it. >>>> >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>> >>>>> I use pickles extensively and they are used also by network objects. >>>>> I've never used LAZYALIGN. >>>>> My vote is that we don't break something (pickles/netobj) to add >>>>> support for something that is rarely used. >>>>> Regards, >>>>> Randy >>>>> >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>>> PM >>> >>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>> requiring existing pickle files to be regenerated and/or existing >>>>> code that reads/writes pickles to need recompilation. >>>>> >>>>> Anybody on this list who has code that might be affected if pickles >>>>> or compiled code were invalidated by a change? >>>>> >>>>> I do propose we change the way of telling the compiler to do >>>>> LAZYALIGN so that it is a property of a type and affects all >>>>> variables of that type. >>>>> >>>>> Olaf Wagner wrote: >>>>> > Perhaps we should check-in this description somewhere near the >>>>> > actual code? Or is there enough documentation already? >>>>> > >>>>> > Olaf >>>>> > >>>>> > PS: Based on your description, I'd say we should abandon >>>>> LAZYALIGN. >>>>> > Or at least put a big sticker on that it will break pickles. >>>>> > >>>>> > Quoting "Rodney M. Bates" : >>>>> > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>>> BITSIZE, >>>>> >> etc. only works for getting object layouts as on the machine >>>>> executing >>>>> >> the code, which is all that is needed when writing a pickle. >>>>> >> >>>>> >> When reading, Pickle code needs to know the layouts of a type >>>>> both as >>>>> >> it is on the reading machine and as it was on the machine that >>>>> wrote >>>>> >> the pickle. The type description that the compiler generates is >>>>> >> excerpted and contains no field displacements, just lists of >>>>> field >>>>> >> types (which are either recursive type descriptions or builtin >>>>> types). >>>>> >> So it is independent of word sizes, etc. >>>>> >> >>>>> >> Pickles regenerates the displacements using the few target >>>>> machine >>>>> >> characteristics in a RTPacking.T It traverses a type >>>>> description and >>>>> >> simultaneously computes two sets of field displacements, both >>>>> as they >>>>> >> are on the reading machine and on the writing machine. For >>>>> the latter, >>>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>>> stored in the >>>>> >> header of the pickle file. For the former, it's gotten by >>>>> techniques >>>>> >> like >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>>> m3core, and >>>>> >> called by Pickle code. >>>>> >> >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>>> layout >>>>> >> behavior. There is no shared code. Making it common would >>>>> involve >>>>> >> quite a bit of rework, as the two use substantially different >>>>> data >>>>> >> structure and code organization. It will be obvious what kind >>>>> of bit >>>>> >> damage could occur if the two algorithms didn't agree. >>>>> >> >>>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>>> comparing the >>>>> >> field displacement computations in RTTipe and in the >>>>> compiler. The >>>>> >> former is oblivious to LAZYALIGN. >>>>> >> >>>>> >> Note that all this is required even without any packing of >>>>> small fields >>>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>>> on a >>>>> >> 32-bit machine and unpickled on a 64. >>>>> >> >>>>> >> Tony Hosking wrote: >>>>> >> >>>>> >>> Rodney, >>>>> >>> >>>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>> >>> would have thought all packing is done on word-sized units >>>>> anyway. >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>>> figure >>>>> >>> out what to do presumably no differently from the way >>>>> INTEGER is >>>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>>> >>> something? >>>>> >>> >>>>> >>> -- Tony >>>>> >>> >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>> >>> >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>> help with? >>>>> >>>> >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>> >>>> >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> >>>>> (which can vary independently of the size of INTEGER). >>>>> >>>>> 2) Variable length values of subrange bounds found in type >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> >>>>> what the native word size can represent. >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>> recently) >>>>> >>>>> is not handled by Pickles. >>>>> >>>>> >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>> >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------------------------------------------------------------- >>>>> >>>>> 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 >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> -- >>>>> >> ------------------------------------------------------------- >>>>> >> 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 >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 hosking at cs.purdue.edu Tue Feb 19 05:40:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 23:40:47 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Message-ID: <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> Thanks for the explanation! How does one express the alignment you support? It does sound like <*LAZYALIGN*> can go away. On Feb 18, 2008, at 8:44 PM, Darko wrote: > Actually rather than compilain rather grumpily, maybe I can just > make the > changes required to RTTipe and do the work to reomve the pragma. I can > work with Randy to ensure it doesn't break pickles, there is no > reason why > it should. > > On tha subject Randy, I assume pickles encode the number of BITS FOR > for a field? If not it should. > > >> We seem to be going through these same point several times. I'm >> not sure >> what the difficulty is, I'm just repeating myself. >> >> Keep in mind this applies *only* to packed structures, ie BIT FOR >> or bit >> fields. >> >> The change I put in libralised the *M3* alignment rules so that >> BITS FOR >> fields in structures would align on byte boundries if possible >> instead of >> restricting them to word alignment generally. GCC happily >> generates code >> for this. There may be restrictions in GCC's C as to how you can >> arrange >> bit fields but I don't see what they have to do with M3. >> >> This is absolutely essentail for using the native APIs on Mac OS X >> and its >> removal would make M3 pointless for use on the Mac, at least more me. >> >> This should be the default behviour. If you are using BITS FOR it's >> becuase you want to arrange the fields in a record in particular >> way. Why >> then arbitrarliy pad out the fields? If performance is an issue, >> the user >> should be using appropriate field bit sizes. The implementation >> rule for >> BITS FOR in M3 is implementation dependent, there are no language >> issues. >> >> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >> created and had nothing to do with me. I diagreed with it and >> never used >> it in the version of the compiler I ran. I support its removal. >> >> >> >>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>> >>>> The alignment behaviour is absolutely crucial to programming >>>> natively in Mac OS X and should be kept. I have a great need for >>>> it. >>>> >>>> The PRGAMA is of no use and can be removed. >>>> >>>> Does anyone have any objections to making this alignment behaviour >>>> standard? >>> >>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>> the standard gcc-backend alignment? Perhaps I don't understand what >>> it is you are doing or trying to do. Again, please remind me >>> what it >>> is that LAZYALIGN does and why it is needed. >>> >>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>> >>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>> Randy that if it is rarely used and moreso breaks things I would >>>>> argue to abandon it. >>>>> >>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>> >>>>>> I use pickles extensively and they are used also by network >>>>>> objects. >>>>>> I've never used LAZYALIGN. >>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>> support for something that is rarely used. >>>>>> Regards, >>>>>> Randy >>>>>> >>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>> PM >>> >>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>> requiring existing pickle files to be regenerated and/or existing >>>>>> code that reads/writes pickles to need recompilation. >>>>>> >>>>>> Anybody on this list who has code that might be affected if >>>>>> pickles >>>>>> or compiled code were invalidated by a change? >>>>>> >>>>>> I do propose we change the way of telling the compiler to do >>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>> variables of that type. >>>>>> >>>>>> Olaf Wagner wrote: >>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>> actual code? Or is there enough documentation already? >>>>>>> >>>>>>> Olaf >>>>>>> >>>>>>> PS: Based on your description, I'd say we should abandon >>>>>> LAZYALIGN. >>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>> >>>>>>> Quoting "Rodney M. Bates" : >>>>>>> >>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>> BITSIZE, >>>>>>>> etc. only works for getting object layouts as on the machine >>>>>> executing >>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>> >>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>> both as >>>>>>>> it is on the reading machine and as it was on the machine that >>>>>> wrote >>>>>>>> the pickle. The type description that the compiler >>>>>>>> generates is >>>>>>>> excerpted and contains no field displacements, just lists of >>>>>> field >>>>>>>> types (which are either recursive type descriptions or builtin >>>>>> types). >>>>>>>> So it is independent of word sizes, etc. >>>>>>>> >>>>>>>> Pickles regenerates the displacements using the few target >>>>>> machine >>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>> description and >>>>>>>> simultaneously computes two sets of field displacements, both >>>>>> as they >>>>>>>> are on the reading machine and on the writing machine. For >>>>>> the latter, >>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>> stored in the >>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>> techniques >>>>>>>> like >>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>> m3core, and >>>>>>>> called by Pickle code. >>>>>>>> >>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>> layout >>>>>>>> behavior. There is no shared code. Making it common would >>>>>> involve >>>>>>>> quite a bit of rework, as the two use substantially different >>>>>> data >>>>>>>> structure and code organization. It will be obvious what kind >>>>>> of bit >>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>> >>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>> comparing the >>>>>>>> field displacement computations in RTTipe and in the >>>>>> compiler. The >>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>> >>>>>>>> Note that all this is required even without any packing of >>>>>> small fields >>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>> on a >>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>> >>>>>>>> Tony Hosking wrote: >>>>>>>> >>>>>>>>> Rodney, >>>>>>>>> >>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>> RTPacking? I >>>>>>>>> would have thought all packing is done on word-sized units >>>>>> anyway. >>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>> figure >>>>>>>>> out what to do presumably no differently from the way >>>>>> INTEGER is >>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>> missing >>>>>>>>> something? >>>>>>>>> >>>>>>>>> -- Tony >>>>>>>>> >>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>> help with? >>>>>>>>>> >>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>> >>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>> LONGINT, >>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>> what the native word size can represent. >>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>> recently) >>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>> >>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>> - >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------- >>>>>> 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 rcoleburn at scires.com Tue Feb 19 05:52:26 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 18 Feb 2008 23:52:26 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Message-ID: <47BA1A35.1E75.00D7.1@scires.com> Sorry, but I've never checked to see how pickles represent "BITS FOR". I've used BITS FOR only on rare occasion. My concern about "breaking" is that if a change is made to the encoding of pickles, then all other programs that use pickles would need to be rebuilt in order to remain compatible. I seem to recall that there is a version number that is put into the encoding to help with compatibility and of course we already have pickle, pickle2, netobj, and netobj2. Perhaps your change could be structured in such a way as to still understand the older variants for compatibility. Here is a scenario: Suppose I have a program that uses pickles and/or netobj. A version is built and put into an embedded system. This system shares pickles/netobj with another client program. After the embedded system is fielded, a change is made to the encoding of pickles. New features are added to the client program and it is rebuilt. Now the client program can't share pickles with the embedded system. Scenario2: A program uses pickles to store data in files. If the pickle structure is changed, the program will no longer be able to read its old files without some sort of transformation function on all the files. Regards, Randy >>> "Darko" 2/18/2008 8:44 PM >>> Actually rather than compilain rather grumpily, maybe I can just make the changes required to RTTipe and do the work to reomve the pragma. I can work with Randy to ensure it doesn't break pickles, there is no reason why it should. On tha subject Randy, I assume pickles encode the number of BITS FOR for a field? If not it should. > We seem to be going through these same point several times. I'm not sure > what the difficulty is, I'm just repeating myself. > > Keep in mind this applies *only* to packed structures, ie BIT FOR or bit > fields. > > The change I put in libralised the *M3* alignment rules so that BITS FOR > fields in structures would align on byte boundries if possible instead of > restricting them to word alignment generally. GCC happily generates code > for this. There may be restrictions in GCC's C as to how you can arrange > bit fields but I don't see what they have to do with M3. > > This is absolutely essentail for using the native APIs on Mac OS X and its > removal would make M3 pointless for use on the Mac, at least more me. > > This should be the default behviour. If you are using BITS FOR it's > becuase you want to arrange the fields in a record in particular way. Why > then arbitrarliy pad out the fields? If performance is an issue, the user > should be using appropriate field bit sizes. The implementation rule for > BITS FOR in M3 is implementation dependent, there are no language issues. > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > created and had nothing to do with me. I diagreed with it and never used > it in the version of the compiler I ran. I support its removal. > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: >> >>> The alignment behaviour is absolutely crucial to programming >>> natively in Mac OS X and should be kept. I have a great need for it. >>> >>> The PRGAMA is of no use and can be removed. >>> >>> Does anyone have any objections to making this alignment behaviour >>> standard? >> >> What do you mean make LAZYALIGN standard? Why wouldn't we go with >> the standard gcc-backend alignment? Perhaps I don't understand what >> it is you are doing or trying to do. Again, please remind me what it >> is that LAZYALIGN does and why it is needed. >> >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>> >>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>> Randy that if it is rarely used and moreso breaks things I would >>>> argue to abandon it. >>>> >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>> >>>>> I use pickles extensively and they are used also by network objects. >>>>> I've never used LAZYALIGN. >>>>> My vote is that we don't break something (pickles/netobj) to add >>>>> support for something that is rarely used. >>>>> Regards, >>>>> Randy >>>>> >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>>> PM >>> >>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>> requiring existing pickle files to be regenerated and/or existing >>>>> code that reads/writes pickles to need recompilation. >>>>> >>>>> Anybody on this list who has code that might be affected if pickles >>>>> or compiled code were invalidated by a change? >>>>> >>>>> I do propose we change the way of telling the compiler to do >>>>> LAZYALIGN so that it is a property of a type and affects all >>>>> variables of that type. >>>>> >>>>> Olaf Wagner wrote: >>>>> > Perhaps we should check-in this description somewhere near the >>>>> > actual code? Or is there enough documentation already? >>>>> > >>>>> > Olaf >>>>> > >>>>> > PS: Based on your description, I'd say we should abandon >>>>> LAZYALIGN. >>>>> > Or at least put a big sticker on that it will break pickles. >>>>> > >>>>> > Quoting "Rodney M. Bates" : >>>>> > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>>> BITSIZE, >>>>> >> etc. only works for getting object layouts as on the machine >>>>> executing >>>>> >> the code, which is all that is needed when writing a pickle. >>>>> >> >>>>> >> When reading, Pickle code needs to know the layouts of a type >>>>> both as >>>>> >> it is on the reading machine and as it was on the machine that >>>>> wrote >>>>> >> the pickle. The type description that the compiler generates is >>>>> >> excerpted and contains no field displacements, just lists of >>>>> field >>>>> >> types (which are either recursive type descriptions or builtin >>>>> types). >>>>> >> So it is independent of word sizes, etc. >>>>> >> >>>>> >> Pickles regenerates the displacements using the few target >>>>> machine >>>>> >> characteristics in a RTPacking.T It traverses a type >>>>> description and >>>>> >> simultaneously computes two sets of field displacements, both >>>>> as they >>>>> >> are on the reading machine and on the writing machine. For >>>>> the latter, >>>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>>> stored in the >>>>> >> header of the pickle file. For the former, it's gotten by >>>>> techniques >>>>> >> like >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>>> m3core, and >>>>> >> called by Pickle code. >>>>> >> >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>>> layout >>>>> >> behavior. There is no shared code. Making it common would >>>>> involve >>>>> >> quite a bit of rework, as the two use substantially different >>>>> data >>>>> >> structure and code organization. It will be obvious what kind >>>>> of bit >>>>> >> damage could occur if the two algorithms didn't agree. >>>>> >> >>>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>>> comparing the >>>>> >> field displacement computations in RTTipe and in the >>>>> compiler. The >>>>> >> former is oblivious to LAZYALIGN. >>>>> >> >>>>> >> Note that all this is required even without any packing of >>>>> small fields >>>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>>> on a >>>>> >> 32-bit machine and unpickled on a 64. >>>>> >> >>>>> >> Tony Hosking wrote: >>>>> >> >>>>> >>> Rodney, >>>>> >>> >>>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>> >>> would have thought all packing is done on word-sized units >>>>> anyway. >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>>> figure >>>>> >>> out what to do presumably no differently from the way >>>>> INTEGER is >>>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>>> >>> something? >>>>> >>> >>>>> >>> -- Tony >>>>> >>> >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>> >>> >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>> help with? >>>>> >>>> >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>> >>>> >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> >>>>> (which can vary independently of the size of INTEGER). >>>>> >>>>> 2) Variable length values of subrange bounds found in type >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> >>>>> what the native word size can represent. >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>> recently) >>>>> >>>>> is not handled by Pickles. >>>>> >>>>> >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>> >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------------------------------------------------------------- >>>>> >>>>> 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 >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> -- >>>>> >> ------------------------------------------------------------- >>>>> >> 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 >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 darko at darko.org Tue Feb 19 11:02:16 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:02:16 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> Message-ID: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> There wouldn't be any explicit expression. in the source, but there would be a flag in Target.i3 for turning it off and on for different platforms. Although the details may be a bit off, the principal is this: before byte alignment change: RECORD a: BITS 8 FOR 0..255; (* takes 32 bits *) b: BITS 32 FOR INTEGER; (* takes 32 bits *) c: BITS 16 FOR 0..65000; (* takes 32 bits *) END; after byte alignment change: RECORD a: BITS 8 FOR 0..255; (* takes 8 bits *) b: BITS 32 FOR INTEGER; (* takes 32 bits *) c: BITS 16 FOR 0..65000; (* takes 16 bits *) END; On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > Thanks for the explanation! How does one express the alignment you > support? > > It does sound like <*LAZYALIGN*> can go away. > > On Feb 18, 2008, at 8:44 PM, Darko wrote: > >> Actually rather than compilain rather grumpily, maybe I can just >> make the >> changes required to RTTipe and do the work to reomve the pragma. I >> can >> work with Randy to ensure it doesn't break pickles, there is no >> reason why >> it should. >> >> On tha subject Randy, I assume pickles encode the number of BITS FOR >> for a field? If not it should. >> >> >>> We seem to be going through these same point several times. I'm >>> not sure >>> what the difficulty is, I'm just repeating myself. >>> >>> Keep in mind this applies *only* to packed structures, ie BIT FOR >>> or bit >>> fields. >>> >>> The change I put in libralised the *M3* alignment rules so that >>> BITS FOR >>> fields in structures would align on byte boundries if possible >>> instead of >>> restricting them to word alignment generally. GCC happily >>> generates code >>> for this. There may be restrictions in GCC's C as to how you can >>> arrange >>> bit fields but I don't see what they have to do with M3. >>> >>> This is absolutely essentail for using the native APIs on Mac OS X >>> and its >>> removal would make M3 pointless for use on the Mac, at least more >>> me. >>> >>> This should be the default behviour. If you are using BITS FOR it's >>> becuase you want to arrange the fields in a record in particular >>> way. Why >>> then arbitrarliy pad out the fields? If performance is an issue, >>> the user >>> should be using appropriate field bit sizes. The implementation >>> rule for >>> BITS FOR in M3 is implementation dependent, there are no language >>> issues. >>> >>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>> created and had nothing to do with me. I diagreed with it and >>> never used >>> it in the version of the compiler I ran. I support its removal. >>> >>> >>> >>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>> >>>>> The alignment behaviour is absolutely crucial to programming >>>>> natively in Mac OS X and should be kept. I have a great need for >>>>> it. >>>>> >>>>> The PRGAMA is of no use and can be removed. >>>>> >>>>> Does anyone have any objections to making this alignment behaviour >>>>> standard? >>>> >>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>> the standard gcc-backend alignment? Perhaps I don't understand >>>> what >>>> it is you are doing or trying to do. Again, please remind me >>>> what it >>>> is that LAZYALIGN does and why it is needed. >>>> >>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>> >>>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>> argue to abandon it. >>>>>> >>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>> >>>>>>> I use pickles extensively and they are used also by network >>>>>>> objects. >>>>>>> I've never used LAZYALIGN. >>>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>>> support for something that is rarely used. >>>>>>> Regards, >>>>>>> Randy >>>>>>> >>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>> PM >>> >>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>> existing >>>>>>> code that reads/writes pickles to need recompilation. >>>>>>> >>>>>>> Anybody on this list who has code that might be affected if >>>>>>> pickles >>>>>>> or compiled code were invalidated by a change? >>>>>>> >>>>>>> I do propose we change the way of telling the compiler to do >>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>> variables of that type. >>>>>>> >>>>>>> Olaf Wagner wrote: >>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>> actual code? Or is there enough documentation already? >>>>>>>> >>>>>>>> Olaf >>>>>>>> >>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>> LAZYALIGN. >>>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>>> >>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>> >>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>> BITSIZE, >>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>> executing >>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>> >>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>> both as >>>>>>>>> it is on the reading machine and as it was on the machine that >>>>>>> wrote >>>>>>>>> the pickle. The type description that the compiler >>>>>>>>> generates is >>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>> field >>>>>>>>> types (which are either recursive type descriptions or builtin >>>>>>> types). >>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>> >>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>> machine >>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>> description and >>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>> as they >>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>> the latter, >>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>> stored in the >>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>> techniques >>>>>>>>> like >>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>> m3core, and >>>>>>>>> called by Pickle code. >>>>>>>>> >>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>> layout >>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>> involve >>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>> data >>>>>>>>> structure and code organization. It will be obvious what kind >>>>>>> of bit >>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>> >>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>> comparing the >>>>>>>>> field displacement computations in RTTipe and in the >>>>>>> compiler. The >>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>> >>>>>>>>> Note that all this is required even without any packing of >>>>>>> small fields >>>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>>> on a >>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>> >>>>>>>>> Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> Rodney, >>>>>>>>>> >>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>> RTPacking? I >>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>> anyway. >>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>> figure >>>>>>>>>> out what to do presumably no differently from the way >>>>>>> INTEGER is >>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>> missing >>>>>>>>>> something? >>>>>>>>>> >>>>>>>>>> -- Tony >>>>>>>>>> >>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>> help with? >>>>>>>>>>> >>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>> >>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>> LONGINT, >>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>> recently) >>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>> >>>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>>> >>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------- >>>>>>> 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 darko at darko.org Tue Feb 19 09:50:38 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 19:50:38 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BA1A35.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <47BA1A35.1E75.00D7.1@scires.com> Message-ID: I agree that pickles should not break. I'm not convinced this alignment change break pickles since it doesn't do anything but change the padding of fields in structures, which is going to change between platforms anyway. Or maybe pickles don't support bit fields anyway. Do pickles use RTTipe exclusively or does it do its own hacking too? On 19/02/2008, at 3:52 PM, Randy Coleburn wrote: > Sorry, but I've never checked to see how pickles represent "BITS FOR". > I've used BITS FOR only on rare occasion. > > My concern about "breaking" is that if a change is made to the > encoding of pickles, then all other programs that use pickles would > need to be rebuilt in order to remain compatible. I seem to recall > that there is a version number that is put into the encoding to help > with compatibility and of course we already have pickle, pickle2, > netobj, and netobj2. Perhaps your change could be structured in > such a way as to still understand the older variants for > compatibility. > > Here is a scenario: Suppose I have a program that uses pickles and/ > or netobj. A version is built and put into an embedded system. > This system shares pickles/netobj with another client program. > After the embedded system is fielded, a change is made to the > encoding of pickles. New features are added to the client program > and it is rebuilt. Now the client program can't share pickles with > the embedded system. > > Scenario2: A program uses pickles to store data in files. If the > pickle structure is changed, the program will no longer be able to > read its old files without some sort of transformation function on > all the files. > > Regards, > Randy > > >>> "Darko" 2/18/2008 8:44 PM >>> > Actually rather than compilain rather grumpily, maybe I can just > make the > changes required to RTTipe and do the work to reomve the pragma. I can > work with Randy to ensure it doesn't break pickles, there is no > reason why > it should. > > On tha subject Randy, I assume pickles encode the number of BITS FOR > for a field? If not it should. > > > > We seem to be going through these same point several times. I'm > not sure > > what the difficulty is, I'm just repeating myself. > > > > Keep in mind this applies *only* to packed structures, ie BIT FOR > or bit > > fields. > > > > The change I put in libralised the *M3* alignment rules so that > BITS FOR > > fields in structures would align on byte boundries if possible > instead of > > restricting them to word alignment generally. GCC happily > generates code > > for this. There may be restrictions in GCC's C as to how you can > arrange > > bit fields but I don't see what they have to do with M3. > > > > This is absolutely essentail for using the native APIs on Mac OS X > and its > > removal would make M3 pointless for use on the Mac, at least more > me. > > > > This should be the default behviour. If you are using BITS FOR it's > > becuase you want to arrange the fields in a record in particular > way. Why > > then arbitrarliy pad out the fields? If performance is an issue, > the user > > should be using appropriate field bit sizes. The implementation > rule for > > BITS FOR in M3 is implementation dependent, there are no language > issues. > > > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > > created and had nothing to do with me. I diagreed with it and > never used > > it in the version of the compiler I ran. I support its removal. > > > > > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: > >> > >>> The alignment behaviour is absolutely crucial to programming > >>> natively in Mac OS X and should be kept. I have a great need for > it. > >>> > >>> The PRGAMA is of no use and can be removed. > >>> > >>> Does anyone have any objections to making this alignment behaviour > >>> standard? > >> > >> What do you mean make LAZYALIGN standard? Why wouldn't we go with > >> the standard gcc-backend alignment? Perhaps I don't understand > what > >> it is you are doing or trying to do. Again, please remind me > what it > >> is that LAZYALIGN does and why it is needed. > >> > >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > >>> > >>>> Can someone remind me again why we need LAZYALIGN? I concur with > >>>> Randy that if it is rarely used and moreso breaks things I would > >>>> argue to abandon it. > >>>> > >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > >>>> > >>>>> I use pickles extensively and they are used also by network > objects. > >>>>> I've never used LAZYALIGN. > >>>>> My vote is that we don't break something (pickles/netobj) to add > >>>>> support for something that is rarely used. > >>>>> Regards, > >>>>> Randy > >>>>> > >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 > >>>>> PM >>> > >>>>> I'll put it in comments in the code. I am sure I can fix it to > >>>>> handle LAZYALIGN too, just not sure whether I can do it without > >>>>> requiring existing pickle files to be regenerated and/or > existing > >>>>> code that reads/writes pickles to need recompilation. > >>>>> > >>>>> Anybody on this list who has code that might be affected if > pickles > >>>>> or compiled code were invalidated by a change? > >>>>> > >>>>> I do propose we change the way of telling the compiler to do > >>>>> LAZYALIGN so that it is a property of a type and affects all > >>>>> variables of that type. > >>>>> > >>>>> Olaf Wagner wrote: > >>>>> > Perhaps we should check-in this description somewhere near the > >>>>> > actual code? Or is there enough documentation already? > >>>>> > > >>>>> > Olaf > >>>>> > > >>>>> > PS: Based on your description, I'd say we should abandon > >>>>> LAZYALIGN. > >>>>> > Or at least put a big sticker on that it will break > pickles. > >>>>> > > >>>>> > Quoting "Rodney M. Bates" : > >>>>> > > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using > >>>>> BITSIZE, > >>>>> >> etc. only works for getting object layouts as on the machine > >>>>> executing > >>>>> >> the code, which is all that is needed when writing a pickle. > >>>>> >> > >>>>> >> When reading, Pickle code needs to know the layouts of a type > >>>>> both as > >>>>> >> it is on the reading machine and as it was on the machine > that > >>>>> wrote > >>>>> >> the pickle. The type description that the compiler > generates is > >>>>> >> excerpted and contains no field displacements, just lists of > >>>>> field > >>>>> >> types (which are either recursive type descriptions or > builtin > >>>>> types). > >>>>> >> So it is independent of word sizes, etc. > >>>>> >> > >>>>> >> Pickles regenerates the displacements using the few target > >>>>> machine > >>>>> >> characteristics in a RTPacking.T It traverses a type > >>>>> description and > >>>>> >> simultaneously computes two sets of field displacements, both > >>>>> as they > >>>>> >> are on the reading machine and on the writing machine. For > >>>>> the latter, > >>>>> >> the value of RTPacking.T is (after a compact bit encoding) > >>>>> stored in the > >>>>> >> header of the pickle file. For the former, it's gotten by > >>>>> techniques > >>>>> >> like > >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of > >>>>> m3core, and > >>>>> >> called by Pickle code. > >>>>> >> > >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's > >>>>> layout > >>>>> >> behavior. There is no shared code. Making it common would > >>>>> involve > >>>>> >> quite a bit of rework, as the two use substantially different > >>>>> data > >>>>> >> structure and code organization. It will be obvious what > kind > >>>>> of bit > >>>>> >> damage could occur if the two algorithms didn't agree. > >>>>> >> > >>>>> >> This is why I am obsessing over LAZYALIGN. I have been > >>>>> comparing the > >>>>> >> field displacement computations in RTTipe and in the > >>>>> compiler. The > >>>>> >> former is oblivious to LAZYALIGN. > >>>>> >> > >>>>> >> Note that all this is required even without any packing of > >>>>> small fields > >>>>> >> within words. E.G., a record with two INTEGER fields, > pickled > >>>>> on a > >>>>> >> 32-bit machine and unpickled on a 64. > >>>>> >> > >>>>> >> Tony Hosking wrote: > >>>>> >> > >>>>> >>> Rodney, > >>>>> >>> > >>>>> >>> Why does there need to be an entry for LONGINT in > RTPacking? I > >>>>> >>> would have thought all packing is done on word-sized units > >>>>> anyway. > >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to > >>>>> figure > >>>>> >>> out what to do presumably no differently from the way > >>>>> INTEGER is > >>>>> >>> communicated between 32-bit and 64-bit machines. Am I > missing > >>>>> >>> something? > >>>>> >>> > >>>>> >>> -- Tony > >>>>> >>> > >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >>>>> >>> > >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can > >>>>> help with? > >>>>> >>>> > >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >>>>> >>>> > >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for > LONGINT, > >>>>> >>>>> (which can vary independently of the size of INTEGER). > >>>>> >>>>> 2) Variable length values of subrange bounds found in type > >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond > >>>>> >>>>> what the native word size can represent. > >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added > >>>>> recently) > >>>>> >>>>> is not handled by Pickles. > >>>>> >>>>> > >>>>> >>>>> I have done some coding on this, but have been > interrupted. > >>>>> >>>>> > >>>>> >>>>> Tony Hosking wrote: > >>>>> >>>>> > >>>>> >>>>>> Why is LONGINT for pickles not yet supported? > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> > ------------------------------------------------------------- > >>>>> >>>>> 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 > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >> > >>>>> >> -- > >>>>> >> ------------------------------------------------------------- > >>>>> >> 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 > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> -- > >>>>> ------------------------------------------------------------- > >>>>> 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 darko at darko.org Tue Feb 19 11:04:09 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:04:09 +1100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> I agree that there should be a pre-processor between M3 syntax and C syntax, but this should also be integrated into the build system so that it is transparent. I think the '.mc' extension is already taken though, which is a bummer. I think we should also be aiming to use this tool to automatically convert C header files (with limitations) to M3. The more I think about it the more I wonder if C programers will swallow it: for example VAR params? Further comments are embedded... On 18/02/2008, at 3:26 PM, Jay wrote: > I've been trying to stay out of this... I would have though your input was most appropriate since your a member of the target audience. > If a comment at the top of the file can make the Modula-3 syntax > more like C then.. Not really what we're aiming for. We're looking for a separate C like syntax in separate files. > replace = with == yes > replace := with = yes > make assignment an expression no, that changes the abstract syntax, which is something we're trying to avoid. > lowercase the keywords yes > try to make braces work (with some alteration for C) yes > use type name instead of name : type yes > separate function parameters with commas and require each to state > its type yes > for that matter, subset C and require all declarations be separate > like that? Do you think C programmers would object? > put back ++, --, -=, +=, etc. yes > superset C and let . be used in place of -> yes > new coding style is four space indent with opening braces on their > own line :) I don't do that even in C > Hm. I think if anyone really wants to do this, instead of nit > picking about Modula-3 syntax here and there, go about it in a > slightly different way? We're really not looking to change M3 in any way, just provide an alternate syntax. > Pick apart what defines Modula-3 through much discussion. > Optional safety -- probably but that for these purposes > optional garbage collection -- maybe that too > "object orientation" that is a subset of C++ > try to use C++ syntax? > generics (generic modules) > independently and relatively easily parsable interface definitions > (!) > these are both important, but I think "independent" is more > important > and "relatively easily" could be omitted for the goals of this > exercise > compiles to native code > sizeof(integer) == sizeof(address) (minor detail) > built in sets and good enumerations > arrays; I don't like them starting at non-zero, but enums for their > index are interesting > > Take the existing definition of C and alter it to have these > characteristics very very much like Modula-3 but with very very very > much Modula-3 syntax From darko at darko.org Tue Feb 19 11:32:22 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:32:22 +1100 Subject: [M3devel] ARM_DARWIN? Message-ID: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> I'm interested in targeting Darwin on the ARM processor, to allow software development for Apple touchscreen hardware such as the iPhone and the iPod touch. Is anyone else interested in this? I know there has been some work by others (see posts here by Iztok Kobal) on targeting processors in the ARM family. The hardware mentioned definitely runs Darwin, or something very much like it. Apparently the CPU is an ARM 11 on the iPhone. Apple is due to release an SDK shortly that will almost certainly mean there will be an ARM target in the standard (XCode) toolchain so it should be a matter of adapting Apple's back end as distributed. It would have to be a cross compiler since being hosted on the target hardware isn't very practical. I'd be very interested to hear from anyone with an interest in this platform. Regards, Darko. From jayk123 at hotmail.com Tue Feb 19 15:34:55 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 19 Feb 2008 14:34:55 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: > I would have though your input was most appropriate since your a I thought I was mostly just pissing people off.> > make assignment an expression> > no, that changes the abstract syntax, which is something we're trying > to avoid. Well.. are there no transforms allowed? Or, no growth of the abstract syntax and Modula-3 doesn't necessarily generate every node type, nor maybe does Modula-C generate every node type, but union them? For example version 1 of Modula-C probably doesn't have "objects", and maybe always unsafe, no optional safety? Though, granted, enabling you to state everything in Modula-C that you can state in Modula-3 is probably important. You don't want people chosing one or the other based on needing certain features, only based on taste. (Someone else said "Codula-3". :)) I guess maybe a more important useful angle here is the interop with C headers. VAR parameters..are roughly just pointers, ok. Or like C++ references. btw, while we are on the subject..I like C's looping constructs, the three expression for loop, do, while, break, continue. Is "exit" what I use in Modula-3 for break? I've been writing loops that could terminate once they find something but have to look this up, otherwise have been letting the loop run longer than necessary..which I saw existing code do anyway. - Jay > CC: wagner at elegosoft.com; m3devel at elegosoft.com> From: darko at darko.org> To: jayk123 at hotmail.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> Date: Tue, 19 Feb 2008 21:04:09 +1100> > I agree that there should be a pre-processor between M3 syntax and C > syntax, but this should also be integrated into the build system so > that it is transparent. I think the '.mc' extension is already taken > though, which is a bummer.> > I think we should also be aiming to use this tool to automatically > convert C header files (with limitations) to M3.> > The more I think about it the more I wonder if C programers will > swallow it: for example VAR params?> > Further comments are embedded...> > On 18/02/2008, at 3:26 PM, Jay wrote:> > I've been trying to stay out of this...> > I would have though your input was most appropriate since your a > member of the target audience.> > > If a comment at the top of the file can make the Modula-3 syntax > > more like C then..> > Not really what we're aiming for. We're looking for a separate C like > syntax in separate files.> > > replace = with ==> > yes> > > replace := with => > yes> > > make assignment an expression> > no, that changes the abstract syntax, which is something we're trying > to avoid.> > > lowercase the keywords> > yes> > > try to make braces work (with some alteration for C)> > yes> > > use type name instead of name : type> > yes> > > separate function parameters with commas and require each to state > > its type> > yes> > > for that matter, subset C and require all declarations be separate > > like that?> > Do you think C programmers would object?> > > put back ++, --, -=, +=, etc.> > yes> > > superset C and let . be used in place of ->> > yes> > > new coding style is four space indent with opening braces on their > > own line :)> > I don't do that even in C> > > Hm. I think if anyone really wants to do this, instead of nit > > picking about Modula-3 syntax here and there, go about it in a > > slightly different way?> > We're really not looking to change M3 in any way, just provide an > alternate syntax.> > > > Pick apart what defines Modula-3 through much discussion.> > Optional safety -- probably but that for these purposes> > optional garbage collection -- maybe that too> > "object orientation" that is a subset of C++> > try to use C++ syntax?> > generics (generic modules)> > independently and relatively easily parsable interface definitions > > (!)> > these are both important, but I think "independent" is more > > important> > and "relatively easily" could be omitted for the goals of this > > exercise> > compiles to native code> > sizeof(integer) == sizeof(address) (minor detail)> > built in sets and good enumerations> > arrays; I don't like them starting at non-zero, but enums for their > > index are interesting> >> > Take the existing definition of C and alter it to have these > > characteristics very very much like Modula-3 but with very very very > > much Modula-3 syntax> > > > > > _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 19 15:39:37 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 19 Feb 2008 14:39:37 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: I have some ideas here that I am pretty certain WILL be acceptable. But I'd like to know if the current behavior really isn't. The ideas are: 1) (* A well designed approach might look like this, however how do we determine the target behavior? Seps_t = RECORD (* Whenever a character must be "written", DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep : CHAR; DirSepText : TEXT; END; SepKind_t = { Unix, Win, Winx }; CONST Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; *) and then I think m3middle would have to specify the behavior of each target -- of course most are "Unix". 2) less work for now, very much like the current behavior, except Colon changes from CONST to VAR and is ':' if the environment variable OS == "Windows_NT", else '\000'. The support for backslashes could key off this too, though I believe it is FAR less controversial. Also, I want to move m3path.m3 into a lower layer so it useable a little more. Like into m3quake (QPath?) or m3middle (M3Path?). However I worry about the effect on source control history. Advise? For now I've got one path function in one m3quake file, another path function in another m3quake file, and everything else remaining in cm3/src/M3Path.m3. - Jay From: jayk123 at hotmail.comTo: mika at async.caltech.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 18 Feb 2008 22:27:56 +0000 I'm going to work on this more but not today.I will at least restrict it to check that the next character is a slash.I'm not sure that will satisfy folks.The Pathname module is/was being used but is a little unsatisfactory. > I use colons in filenames a lot Do you use it in source files?For "root" directories, like where your cm3 install/source is? I'm trying to think/wiggle through what might be an acceptable escape.Something like -- where files in general are vs. where "programmer" files are.Putting a colon in a filename really is quite non-portable.And that may or may not matter. The existing Modula-3 code was fairly strict and I very unsure it was right.I had a question drafted to m3devel that I ended up not sending.It went roughly like:" Has anyone done a cross build where host and target vary in naming conventions? I am skeptical that this works, and am strongly considering /slightly/ depending on that or making it "worse". In particular, there is provision in the code for "converting" between host and target paths, but all it does is translate slashes. It doesn't translate libfoo.a to foo.lib for example." Upon further digging though, I decide that my more immediate severe problemcould be dealt with not by making things worse but by making them better.This is the change around checking NAMING_CONVENTIONS earlier.While my analysis was not 100% thorough, it is my very strong suspicionthat the NAMING_CONVENTION and undocumented TARGET_NAMING configurationvariables never really worked. Sure, they affected the name of the .m3x file.But that is about it. I didn't check .exes, but probably didn't work, and what I wasseeing was they didn't work for libraries. M3Path.m3 sets up one set of path data in three ways. variable initialization (VAR foo := 123) module initialization (BEGIN foo := 456 END Module.) and explicit calls after reading the config file The problem was that the explicit calls were very late, so the module initialization is what held.If Join(a,b) == a/b, then you'd get Unix naming conventions./Arguably/ this is exactly correct.But I would like the slash and the "naming" to be separate, at least for now.That is, NT386GNU uses forward slashes but foo.lib instead of libfoo.a.I should try to change that actually.I had trouble changing it for this reason since I was cross building from NT386. The NT386 HOST wants to use Win32 naming conventions, "\" and foo.lib, evenif the config file asks for Unix naming.. Anyway, this is all somewhat of a tangent, one in which I'm more confident of where to go and that what I changed is ok. (It might become irrelevant.) The other issues are around "difficulty" setting paths.I had CM3_ROOT=c:\dev2\cm3.2.That wouldn't necessarily work with NT386GNU. It seems darn near possible to have one path syntax and one set of code for dealing with it.But maybe not.Even semicolon vs. colon seems doable. Specifically, if an element of $PATH appears to be just a single character, that colon is not a $PATH divider. Perhaps I just need to have two sets of CM3_ROOT / CM3_INSTALL and perhaps M3CONFIG variables.I was kind of hoping not. It's worse than that really, since the two hosts can target the two targets, so host and target paths needs to be better distinguished than I believe the are now. I was saying there is code to change the slashes, but there isn't code to deal with a leading drive letter. What I have been particularly avoiding is calls out to cygwin_convert_path or such, but maybe that's what I need to do. Get ROOT / CM3_INSTALL etc. from the command line and environment, convert as appropriate, and move on. ROOT in particular is set by Python. Usually for me that is Win32 Python, but Cygwin Python is an option.So then Python has to know what cm3 it is running?I considered probing it with findstr /i /m cm3.exe cygwin1.dll.I considered something like cm3 -report_something_or_other, kind of like gcc has -print-gcc-lib-name or whatnot. These might still be viable ideas. Historically cross environments don't allow multiple "targets" / "platforms" / "configurations" / "whatever" to run on the same OS. But there is some of an opposite trend. Like how NT386 and NT386GNU run on the same OS. Like SOLsun, SOLgnu. Like x86 on AMD64 operating systems. So maybe a little bit of support is good there, the cm3 -print-slash or cm3 -print-host or something. Also I forgot to point out that Win32 is often find with forward slashes, but notable file.open dialogs are not.I very frequently copy compiler output to file.open dialogs so in some places backward slashes are preferred.A possible strategy is to sniff what the user is using -- such as in any of those environment variables -- and favor it.Or for each Join operating harvest a path separater from the parameters and default if there is none there. I have some code working like that last option right now but it's not quite working and has to wait. It is very reasonable to have Win32 treat forward and backward slashes as the same, in particular.It is fairly reasonable imho for Posix code to also treat them the same but "fixup" backward to forward. As well, on Windows, if you mostly limit yourself to one drive letter, then /foo/bar is a pretty acceptable form.. Anyway...lots of facts, some easy conclusions, some unclear conclusions.I'll fiddle around with it more later.Ideally switching between NT386 and NT386GNU is fairly easy.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 18 Feb 2008 14:04:06 -0800> From: mika at async.caltech.edu> > > I never tried putting it in my PATH, no... You are right, colons> are *slightly* special. I am not in the habit of copying files to> Windows. I only copy files between Unix and Windows to save them> from Windows.> > That being said, I am pretty sure I use colons more in filenames> than I use the letter "q". Could you ban the letter "q" instead? :)> > If you've gotta do it, then do it. It's just ... weird.> > I personally will probably never run into the issue. I use colons> in filenames a lot, but as a separator for various types of data> files. :.> > Is your code able to import (or duplicate...) Pathname? I would> have thought that that interface has all the necessary bits to make> paths portable...> > MIka> > Jay writes:> >--_dfd4e29a-b904-43be-8435-4824d419d270_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> But colons? Colons are not special in any way, shape, or form, on> Unix..=> >. I think "it is extremely surprising" to a Unix user if a path> >Ever try putting a path with a colon into $PATH? Does it work?> >Or copying a file with a colon in its name to a Windows system? Does it wor=> >k?> >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue=> >ss.> >=20> >As a user switching between multiple systems, this area is quite frustratin=> >g...I guess no matter what.> >Sometimes one form works, sometimes another, sometimes either, often with i=> >dentical meaning, but not always.> >These changes, and about one more, should make building NT386GNU a fair amo=> >unt easier..> >=20> >Currently it is any path with a colon in the second character.> >How about if that is further restricted to having a-z in the first characte=> >r and/or more importantly a slash in the third character?> >=20> > - Jay> >> >> > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 19 18:31:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 19 Feb 2008 12:31:23 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> Message-ID: <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> I get an error: "../src/Main.m3", line 6: Could not find a legal alignment for the packed type. for the type: TYPE T = RECORD a: BITS 8 FOR [0..255]; c: BITS 16 FOR [0..65535]; b: BITS 32 FOR INTEGER; END; Are you saying that lazy alignment permits this to compile? This is very scary! What happens if you write the following? TYPE T = RECORD a: BITS 8 FOR [0..255]; c: BITS 16 FOR [0..65535]; b: BITS 32 FOR ROOT; END; Now b is a *hidden* reference (because it is unaligned) that the garbage collector will not find if T describes a stack variable t: PROCEDURE p (x: ROOT) = VAR t: T; BEGIN t.b := x; x := NIL; ... garbage collector runs and moves object referred to by t.b but doesn't find t.b reference in stack! t.b^ causes chaos and destruction... END p; Thus, lazy alignment should only be permitted in UNSAFE modules. I hope that this is the case! On Feb 19, 2008, at 5:02 AM, Darko wrote: > There wouldn't be any explicit expression. in the source, but there > would be a flag in Target.i3 for turning it off and on for > different platforms. > > Although the details may be a bit off, the principal is this: > > before byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 32 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 32 bits *) > END; > > after byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 8 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 16 bits *) > END; > > > On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > >> Thanks for the explanation! How does one express the alignment >> you support? >> >> It does sound like <*LAZYALIGN*> can go away. >> >> On Feb 18, 2008, at 8:44 PM, Darko wrote: >> >>> Actually rather than compilain rather grumpily, maybe I can just >>> make the >>> changes required to RTTipe and do the work to reomve the pragma. >>> I can >>> work with Randy to ensure it doesn't break pickles, there is no >>> reason why >>> it should. >>> >>> On tha subject Randy, I assume pickles encode the number of BITS FOR >>> for a field? If not it should. >>> >>> >>>> We seem to be going through these same point several times. I'm >>>> not sure >>>> what the difficulty is, I'm just repeating myself. >>>> >>>> Keep in mind this applies *only* to packed structures, ie BIT >>>> FOR or bit >>>> fields. >>>> >>>> The change I put in libralised the *M3* alignment rules so that >>>> BITS FOR >>>> fields in structures would align on byte boundries if possible >>>> instead of >>>> restricting them to word alignment generally. GCC happily >>>> generates code >>>> for this. There may be restrictions in GCC's C as to how you can >>>> arrange >>>> bit fields but I don't see what they have to do with M3. >>>> >>>> This is absolutely essentail for using the native APIs on Mac OS >>>> X and its >>>> removal would make M3 pointless for use on the Mac, at least >>>> more me. >>>> >>>> This should be the default behviour. If you are using BITS FOR it's >>>> becuase you want to arrange the fields in a record in particular >>>> way. Why >>>> then arbitrarliy pad out the fields? If performance is an issue, >>>> the user >>>> should be using appropriate field bit sizes. The implementation >>>> rule for >>>> BITS FOR in M3 is implementation dependent, there are no >>>> language issues. >>>> >>>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>>> created and had nothing to do with me. I diagreed with it and >>>> never used >>>> it in the version of the compiler I ran. I support its removal. >>>> >>>> >>>> >>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>> >>>>>> The alignment behaviour is absolutely crucial to programming >>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>> for it. >>>>>> >>>>>> The PRGAMA is of no use and can be removed. >>>>>> >>>>>> Does anyone have any objections to making this alignment >>>>>> behaviour >>>>>> standard? >>>>> >>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>>> the standard gcc-backend alignment? Perhaps I don't understand >>>>> what >>>>> it is you are doing or trying to do. Again, please remind me >>>>> what it >>>>> is that LAZYALIGN does and why it is needed. >>>>> >>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>> >>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>> with >>>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>>> argue to abandon it. >>>>>>> >>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>> >>>>>>>> I use pickles extensively and they are used also by network >>>>>>>> objects. >>>>>>>> I've never used LAZYALIGN. >>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>> add >>>>>>>> support for something that is rarely used. >>>>>>>> Regards, >>>>>>>> Randy >>>>>>>> >>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>> PM >>> >>>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>> without >>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>> existing >>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>> >>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>> pickles >>>>>>>> or compiled code were invalidated by a change? >>>>>>>> >>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>> variables of that type. >>>>>>>> >>>>>>>> Olaf Wagner wrote: >>>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>> LAZYALIGN. >>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>> pickles. >>>>>>>>> >>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>> >>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>>> BITSIZE, >>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>> executing >>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>> >>>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>>> both as >>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>> that >>>>>>>> wrote >>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>> generates is >>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>> field >>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>> builtin >>>>>>>> types). >>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>> >>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>> machine >>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>> description and >>>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>>> as they >>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>> the latter, >>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>> stored in the >>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>> techniques >>>>>>>>>> like >>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>> m3core, and >>>>>>>>>> called by Pickle code. >>>>>>>>>> >>>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>>> layout >>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>> involve >>>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>>> data >>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>> kind >>>>>>>> of bit >>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>> >>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>> comparing the >>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>> compiler. The >>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>> >>>>>>>>>> Note that all this is required even without any packing of >>>>>>>> small fields >>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>> pickled >>>>>>>> on a >>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>> >>>>>>>>>> Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Rodney, >>>>>>>>>>> >>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>> RTPacking? I >>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>> anyway. >>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>> figure >>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>> INTEGER is >>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>> missing >>>>>>>>>>> something? >>>>>>>>>>> >>>>>>>>>>> -- Tony >>>>>>>>>>> >>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>>> help with? >>>>>>>>>>>> >>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>> recently) >>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>> >>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>> interrupted. >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> ---------------------------------------------------------- >>>>>>>>>>>>> --- >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 darko at darko.org Tue Feb 19 21:23:23 2008 From: darko at darko.org (Darko) Date: Wed, 20 Feb 2008 07:23:23 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> Message-ID: Thanks for raising a very good point. I'd say make it that traced references will not be non-word aligned as a part of the alignment behaviour. On 20/02/2008, at 4:31 AM, Tony Hosking wrote: > I get an error: > > "../src/Main.m3", line 6: Could not find a legal alignment for the > packed type. > > for the type: > > TYPE > T = RECORD > a: BITS 8 FOR [0..255]; > c: BITS 16 FOR [0..65535]; > b: BITS 32 FOR INTEGER; > END; > > Are you saying that lazy alignment permits this to compile? > > > This is very scary! What happens if you write the following? > > TYPE > T = RECORD > a: BITS 8 FOR [0..255]; > c: BITS 16 FOR [0..65535]; > b: BITS 32 FOR ROOT; > END; > > Now b is a *hidden* reference (because it is unaligned) that the > garbage collector will not find if T describes a stack variable t: > > PROCEDURE p (x: ROOT) = > VAR t: T; > BEGIN > t.b := x; > x := NIL; > ... > garbage collector runs and moves object referred to by t.b but > doesn't find t.b reference in stack! > t.b^ causes chaos and destruction... > END p; > > Thus, lazy alignment should only be permitted in UNSAFE modules. I > hope that this is the case! > > On Feb 19, 2008, at 5:02 AM, Darko wrote: > >> There wouldn't be any explicit expression. in the source, but there >> would be a flag in Target.i3 for turning it off and on for >> different platforms. >> >> Although the details may be a bit off, the principal is this: >> >> before byte alignment change: >> >> RECORD >> a: BITS 8 FOR 0..255; (* takes 32 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >> END; >> >> after byte alignment change: >> >> RECORD >> a: BITS 8 FOR 0..255; (* takes 8 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >> END; >> >> >> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >> >>> Thanks for the explanation! How does one express the alignment >>> you support? >>> >>> It does sound like <*LAZYALIGN*> can go away. >>> >>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>> >>>> Actually rather than compilain rather grumpily, maybe I can just >>>> make the >>>> changes required to RTTipe and do the work to reomve the pragma. >>>> I can >>>> work with Randy to ensure it doesn't break pickles, there is no >>>> reason why >>>> it should. >>>> >>>> On tha subject Randy, I assume pickles encode the number of BITS >>>> FOR >>>> for a field? If not it should. >>>> >>>> >>>>> We seem to be going through these same point several times. I'm >>>>> not sure >>>>> what the difficulty is, I'm just repeating myself. >>>>> >>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>> FOR or bit >>>>> fields. >>>>> >>>>> The change I put in libralised the *M3* alignment rules so that >>>>> BITS FOR >>>>> fields in structures would align on byte boundries if possible >>>>> instead of >>>>> restricting them to word alignment generally. GCC happily >>>>> generates code >>>>> for this. There may be restrictions in GCC's C as to how you can >>>>> arrange >>>>> bit fields but I don't see what they have to do with M3. >>>>> >>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>> X and its >>>>> removal would make M3 pointless for use on the Mac, at least >>>>> more me. >>>>> >>>>> This should be the default behviour. If you are using BITS FOR >>>>> it's >>>>> becuase you want to arrange the fields in a record in particular >>>>> way. Why >>>>> then arbitrarliy pad out the fields? If performance is an issue, >>>>> the user >>>>> should be using appropriate field bit sizes. The implementation >>>>> rule for >>>>> BITS FOR in M3 is implementation dependent, there are no >>>>> language issues. >>>>> >>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>> Olaf >>>>> created and had nothing to do with me. I diagreed with it and >>>>> never used >>>>> it in the version of the compiler I ran. I support its removal. >>>>> >>>>> >>>>> >>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>> >>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>> for it. >>>>>>> >>>>>>> The PRGAMA is of no use and can be removed. >>>>>>> >>>>>>> Does anyone have any objections to making this alignment >>>>>>> behaviour >>>>>>> standard? >>>>>> >>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>> with >>>>>> the standard gcc-backend alignment? Perhaps I don't understand >>>>>> what >>>>>> it is you are doing or trying to do. Again, please remind me >>>>>> what it >>>>>> is that LAZYALIGN does and why it is needed. >>>>>> >>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>> >>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>> with >>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>> would >>>>>>>> argue to abandon it. >>>>>>>> >>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>> >>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>> objects. >>>>>>>>> I've never used LAZYALIGN. >>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>> add >>>>>>>>> support for something that is rarely used. >>>>>>>>> Regards, >>>>>>>>> Randy >>>>>>>>> >>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>> PM >>> >>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>> to >>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>> without >>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>> existing >>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>> >>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>> >>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>> variables of that type. >>>>>>>>> >>>>>>>>> Olaf Wagner wrote: >>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>> the >>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>> LAZYALIGN. >>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>> pickles. >>>>>>>>>> >>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>> >>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>> Using >>>>>>>>> BITSIZE, >>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>> executing >>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>> >>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>> type >>>>>>>>> both as >>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>> that >>>>>>>>> wrote >>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>> generates is >>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>> field >>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>> builtin >>>>>>>>> types). >>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>> >>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>> machine >>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>> description and >>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>> both >>>>>>>>> as they >>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>> the latter, >>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>> stored in the >>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>> techniques >>>>>>>>>>> like >>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>> m3core, and >>>>>>>>>>> called by Pickle code. >>>>>>>>>>> >>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>> compiler's >>>>>>>>> layout >>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>> involve >>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>> different >>>>>>>>> data >>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>> kind >>>>>>>>> of bit >>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>> >>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>> comparing the >>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>> compiler. The >>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>> >>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>> small fields >>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>> pickled >>>>>>>>> on a >>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Rodney, >>>>>>>>>>>> >>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>> RTPacking? I >>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>> anyway. >>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>> figure >>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>> INTEGER is >>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>> missing >>>>>>>>>>>> something? >>>>>>>>>>>> >>>>>>>>>>>> -- Tony >>>>>>>>>>>> >>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>> can >>>>>>>>> help with? >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>> type >>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>> recently) >>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 Feb 21 11:42:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 11:42:25 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Quoting Jay : > I have some ideas here that I am pretty certain WILL be acceptable. > But I'd like to know if the current behavior really isn't. > > The ideas are: > 1) > (* A well designed approach might look like this, however how do > we determine the target behavior? > Seps_t = RECORD (* Whenever a character must be "written", > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > : CHAR; DirSepText : TEXT; END; > SepKind_t = { Unix, Win, Winx }; > > CONST > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; > *) > and then I think m3middle would have to specify the behavior of each > target -- of course most are "Unix". > > 2) less work for now, very much like the current behavior, except > Colon changes from CONST to VAR and is ':' if the environment > variable OS == "Windows_NT", else '\000'. The support for > backslashes could key off this too, though I believe it is FAR less > controversial. > > Also, I want to move m3path.m3 into a lower layer so it useable a > little more. > Like into m3quake (QPath?) or m3middle (M3Path?). > > However I worry about the effect on source control history. > Advise? > > For now I've got one path function in one m3quake file, another path > function in another m3quake file, and everything else remaining in > cm3/src/M3Path.m3. I agree that we should have one central abstraction of the pathanme type. What about pushing it further into libm3/.../Pathname? This would need carefully checking of compatibility of course. Also I wouldn't like to see variables exposed in such a module; we should use functions or procedures for everything there. Do you see any problem in providing such a globally unique and compatible abstraction? Could you provide a complete (documented) Pathname module that could be discussed on this list and tested by everybody interested? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 11:55:05 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 21 Feb 2008 02:55:05 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Mon, 18 Feb 2008 23:52:26 EST." <47BA1A35.1E75.00D7.1@scires.com> Message-ID: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> Ugh!!! I am still using compilers that are almost ten years old on ALL my systems just because I need to share pickles between them and CM3 has a different TEXT format from my ancient PM3. Tony thinks there's a workaround with specials but I haven't had a chance to get to it yet... "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part6F499F9A.2__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Sorry, but I've never checked to see how pickles represent "BITS FOR". >I've used BITS FOR only on rare occasion. >=20 >My concern about "breaking" is that if a change is made to the encoding of = >pickles, then all other programs that use pickles would need to be rebuilt = >in order to remain compatible. I seem to recall that there is a version = >number that is put into the encoding to help with compatibility and of = >course we already have pickle, pickle2, netobj, and netobj2. Perhaps your = >change could be structured in such a way as to still understand the older = >variants for compatibility. >=20 >Here is a scenario: Suppose I have a program that uses pickles and/or = >netobj. A version is built and put into an embedded system. This system = >shares pickles/netobj with another client program. After the embedded = >system is fielded, a change is made to the encoding of pickles. New = >features are added to the client program and it is rebuilt. Now the = >client program can't share pickles with the embedded system. >=20 >Scenario2: A program uses pickles to store data in files. If the pickle = >structure is changed, the program will no longer be able to read its old = >files without some sort of transformation function on all the files. >=20 >Regards, >Randy From lemming at henning-thielemann.de Thu Feb 21 13:22:50 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Feb 2008 13:22:50 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: On Tue, 19 Feb 2008, Darko wrote: > I agree that there should be a pre-processor between M3 syntax and C > syntax, but this should also be integrated into the build system so > that it is transparent. I think the '.mc' extension is already taken > though, which is a bummer. > > I think we should also be aiming to use this tool to automatically > convert C header files (with limitations) to M3. You won't be happy with such conversions. The results of translations with SWIG using manual annotations are better, but you quickly run into writing more annotation than converting the C header manually. From darko at darko.org Thu Feb 21 13:48:17 2008 From: darko at darko.org (Darko) Date: Thu, 21 Feb 2008 23:48:17 +1100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: I find converting C headers manually not too bad using a few standard regexes and a couple of rules of thumb. I was hoping something like this could be done with exceptions handled manually. I don't think complete automatic conversion is practical as you say, but there must be something better and more productive than manual conversions. On 21/02/2008, at 11:22 PM, Henning Thielemann wrote: > > On Tue, 19 Feb 2008, Darko wrote: > >> I agree that there should be a pre-processor between M3 syntax and C >> syntax, but this should also be integrated into the build system so >> that it is transparent. I think the '.mc' extension is already taken >> though, which is a bummer. >> >> I think we should also be aiming to use this tool to automatically >> convert C header files (with limitations) to M3. > > You won't be happy with such conversions. The results of > translations with > SWIG using manual annotations are better, but you quickly run into > writing > more annotation than converting the C header manually. From jayk123 at hotmail.com Thu Feb 21 13:56:34 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 21 Feb 2008 12:56:34 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: "Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix. And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong. That is, "cleanup" of a/./b to a/b, a/../b to b. Incorrect in the face of links. But still general purpose if people want it. The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target". This is specially just changing slashes around. It does not deal with "drive letters". It deals with "file types". This is an area that probably does not belong in libm3. "types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib. There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix. Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward. It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data. As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo but when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Feb 21 14:39:21 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Feb 2008 14:39:21 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: On Thu, 21 Feb 2008, Darko wrote: > I find converting C headers manually not too bad using a few standard > regexes and a couple of rules of thumb. I was hoping something like > this could be done with exceptions handled manually. I don't think > complete automatic conversion is practical as you say, but there must > be something better and more productive than manual conversions. You can try to improve the attempts I contributed to SWIG. From dragisha at m3w.org Thu Feb 21 17:08:04 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 21 Feb 2008 17:08:04 +0100 Subject: [M3devel] Building minimal and fresh cm3... Message-ID: <1203610084.11244.14.camel@hias.m3w.org> I am trying to make minimal binary rpm for latest cm3. I am creating it's contents with: *** copied and edited cm3.cfg for new root. Set M3CONFIG to point to it. *** copied cm3cg into new .../bin (Do I need ONLY these three files for bootstrap only??? cm3, cm3cg and cm3.cfg) *** checked out yesterday's head *** did ./scripts/do-cm3-std.sh buildship At this moment, I would like to bootstrap new compiler. I see there's "sysutils" package now, so probably I have to modify former list of packages, and I did it so I typed: *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; cm3 -ship) All went well, except I had to add m3objfile (and later m3back) because of: "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/m3makefile", line 24: quake runtime error: unable to open "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading I supposse I also have to build m3cc so I have latest cm3cg? *** did ./scripts/do-cm3-std.sh buildship so all is build with latest cm3. Is this all I need to have brand new hierarchy I can pack into rpm and distribute? dd -- Dragi?a Duri? From wagner at elegosoft.com Thu Feb 21 17:48:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 17:48:30 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> Quoting Jay : > I'd like to make "progress" on what I have -- mainly slash > independence, no colon hack on Unix. > And then see about making much more progress. OK. > M3Path compromises a few bits of functionality, some of which could > go in libm3, but not all. > > It has "path cleanup", of a sort that was strongly suggested here to > be wrong. > That is, "cleanup" of a/./b to a/b, a/../b to b. > Incorrect in the face of links. > But still general purpose if people want it. > The code that does this work I think can stand a rewrite. It is > currently limited to 31 slashes and after that it just silently > ignores stuff. If you reverse the path first, do the work, reverse > again, you can support unlimited lengths with small fixed memory > (smaller than it currently uses to support limit lengths). > > It has "path conversion" between "host" and "target". > This is specially just changing slashes around. > It does not deal with "drive letters". I see. This could be abstracted, too, though. > It deals with "file types". > This is an area that probably does not belong in libm3. > "types" are, you know, .m3, .i3, reasonably simple, but also > libfoo.a vs. foo.lib. > There is code to pick apart paths to "in that way", which I find..a > little unusual. OK. This is rather compiler specific. > I did already change the Win32 Pathname implementation to > always/usually treat forward and backward slashes as the same. That > goes pretty far. > > I believe the Pathname abstraction is that a path is essentially an > array of strings, you can add/remove from either end, add to one or > the other or both ends, and join two. Yes, but it could be extended. There is also some support for different kinds of `roots'. > An issue I'm avoiding..because I don't want to pollute the code with > calls out ot Cygwin, is "correct" conversion between Win32 and > Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. > > I haven't seen how "network paths" are handled. > > Path handling is a surprisingly large rats nest of subtle behaviors > and I'm not sure I really want to open it. I'll second that. > Really, there are a few Win32 behaviors that i haven't gotten into.. > > Even if you ignore Win32 -- what about case sensitivity? Even on Mac > and presumably Unix (to a Mac or Windows server), you can encounter > case insensitive file systems. The current Modula-3 code is not > prepared for that. Case sensitivity of file names should be handled centrally, too. It could be a property of a filename. But then that property needs to be set by someone - runtime, environment, user, application... As this is a big issue for portability of code, I'd say we should come up with some sound concept here, but of course that can be independent of your current work. > One of my favorite sob stories here, I've probably told it here, is > that I have a low end NAS (it won't boot lately..). It runs Linux, > of course (I said it is low end). I downloaded it source, extracted > it, xcopied, xcopyied it again incrementally. That fails. Because > some of the file names start with a dot and on Unix, that means they > are hidden and cannot be unhidden.. `Hidden' on Unix usually only means that files are not shown with a simple `ls'. There's nothing special in the system to treat dot-files different from others as far as I know. > So this whole "hidden" thing is not portable, just as colons in > paths are not portable, but they work just fine if you stay on one > system... > Let me get M3Path to where I want it, and repair the Unix colon > behavior, and see about rewriting the "cleanup" code... as long as > folks are happy with how it ends up, I'm not sure I want to puruse > it much more. There are much bigger fish... OK, I can understand that you just want to finishd your current work. > Oh, I already have code on my system so that when we read ROOT, > CM3_INSTALL, CM3_ROOT from the command line and/or environment, > those paths get "fixed up" -- slashes reversed. That should help a > lot here, without much pollution.. It should help, but it also needs to be tested on different platforms. > One thing I'm not sure about is the treatment of backward slashes > equivalent to forward slashes on Posix. > Maybe better just to do that fixup upon a few certain inputs. And > have Win32 use either, but Posix only forward. > It's "harmless" but loose. Yes, I'd be rather conservative there, too. > There this general problem of "user input" vs. "internal, strongly > typed, analyzed, rule-following" data. > As well as then presenting the internal data back to the user in the > form he expected. > > It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo > but when an error message is reported, in case I am going to > copy/paste the paths in it to file.open, it should be back with > backward slashes. This is not simple. You could maintain two > parallel representations as you muck with the path. Not great. You > could "characterize" the form of the user in put (which slash > directory), keep that around, it's just one bit, and use it to guide > the later presentation... One internal, abstract representation of the data, and two or more views on it (getPosixPath, getWindowsPath, ...) come to mind here. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 18:25:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:25:35 -0500 Subject: [M3devel] ARM_DARWIN? In-Reply-To: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> References: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> Message-ID: I am interested, though I don't have any immediate need. On Feb 19, 2008, at 5:32 AM, Darko wrote: > I'm interested in targeting Darwin on the ARM processor, to allow > software development for Apple touchscreen hardware such as the > iPhone and the iPod touch. Is anyone else interested in this? I > know there has been some work by others (see posts here by Iztok > Kobal) on targeting processors in the ARM family. > > The hardware mentioned definitely runs Darwin, or something very > much like it. Apparently the CPU is an ARM 11 on the iPhone. > > Apple is due to release an SDK shortly that will almost certainly > mean there will be an ARM target in the standard (XCode) toolchain > so it should be a matter of adapting Apple's back end as > distributed. It would have to be a cross compiler since being > hosted on the target hardware isn't very practical. > > I'd be very interested to hear from anyone with an interest in this > platform. > > Regards, > Darko. From hosking at cs.purdue.edu Thu Feb 21 18:44:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:44:00 -0500 Subject: [M3devel] Building minimal and fresh cm3... In-Reply-To: <1203610084.11244.14.camel@hias.m3w.org> References: <1203610084.11244.14.camel@hias.m3w.org> Message-ID: Yes, a number of packages got added to the minimal distro. I would have preferred to avoid m3objfile and m3back since they are (currently) only for Windows targets, but they may become more useful on other x86 platforms in future. On Feb 21, 2008, at 11:08 AM, Dragi?a Duri? wrote: > I am trying to make minimal binary rpm for latest cm3. I am creating > it's contents with: > > *** copied and edited cm3.cfg for new root. Set M3CONFIG to point > to it. > > *** copied cm3cg into new .../bin (Do I need ONLY these three files > for > bootstrap only??? cm3, cm3cg and cm3.cfg) > > *** checked out yesterday's head > > *** did ./scripts/do-cm3-std.sh buildship > > At this moment, I would like to bootstrap new compiler. I see there's > "sysutils" package now, so probably I have to modify former list of > packages, and I did it so I typed: > > *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker > m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; > cm3 -ship) > > All went well, except I had to add m3objfile (and later m3back) > because > of: > > "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/ > m3makefile", > line 24: quake runtime error: unable to open > "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading > > I supposse I also have to build m3cc so I have latest cm3cg? > > *** did ./scripts/do-cm3-std.sh buildship so all is build with latest > cm3. > > Is this all I need to have brand new hierarchy I can pack into rpm > and > distribute? > > dd > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Thu Feb 21 18:54:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:54:54 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> Message-ID: I will dip my toe into this swamp only to make some high-level observations. First, until we can come up with a well-specified abstraction in the form of a clean M3 interface I for one will find it increasingly difficult to follow the motivation and developments of any scheme. In the face of that difficulty, I strongly prefer to stick to the current, non-portable, approach (ie, different path encodings for different targets maintained *separately*). This will minimize disturbance for the many of us that only work on POSIX targets and need those to stay stable. I am very nervous that my POSIX target will start to behave strangely or differently because of some interim commit to a rapidly evolving code base. Hence, I applaud Olaf's suggestion that we come up with a clean design before we start hacking, and that the implementation stay off the critical path until it has been well-tested and understood. On Feb 21, 2008, at 11:48 AM, Olaf Wagner wrote: > Quoting Jay : >> I'd like to make "progress" on what I have -- mainly slash >> independence, no colon hack on Unix. >> And then see about making much more progress. > > OK. > >> M3Path compromises a few bits of functionality, some of which >> could go in libm3, but not all. >> >> It has "path cleanup", of a sort that was strongly suggested here >> to be wrong. >> That is, "cleanup" of a/./b to a/b, a/../b to b. >> Incorrect in the face of links. >> But still general purpose if people want it. >> The code that does this work I think can stand a rewrite. It is >> currently limited to 31 slashes and after that it just silently >> ignores stuff. If you reverse the path first, do the work, >> reverse again, you can support unlimited lengths with small fixed >> memory (smaller than it currently uses to support limit lengths). >> >> It has "path conversion" between "host" and "target". >> This is specially just changing slashes around. >> It does not deal with "drive letters". > > I see. This could be abstracted, too, though. > >> It deals with "file types". >> This is an area that probably does not belong in libm3. >> "types" are, you know, .m3, .i3, reasonably simple, but also >> libfoo.a vs. foo.lib. >> There is code to pick apart paths to "in that way", which I >> find..a little unusual. > > OK. This is rather compiler specific. > >> I did already change the Win32 Pathname implementation to always/ >> usually treat forward and backward slashes as the same. That goes >> pretty far. >> >> I believe the Pathname abstraction is that a path is essentially >> an array of strings, you can add/remove from either end, add to >> one or the other or both ends, and join two. > > Yes, but it could be extended. There is also some support for > different kinds of `roots'. > >> An issue I'm avoiding..because I don't want to pollute the code >> with calls out ot Cygwin, is "correct" conversion between Win32 >> and Cygwin paths. Generally the conversion is c:\foo <=> / >> cygdrive/foo. >> >> I haven't seen how "network paths" are handled. >> >> Path handling is a surprisingly large rats nest of subtle >> behaviors and I'm not sure I really want to open it. > > I'll second that. > >> Really, there are a few Win32 behaviors that i haven't gotten into.. >> >> Even if you ignore Win32 -- what about case sensitivity? Even on >> Mac and presumably Unix (to a Mac or Windows server), you can >> encounter case insensitive file systems. The current Modula-3 >> code is not prepared for that. > > Case sensitivity of file names should be handled centrally, too. > It could be a property of a filename. But then that property needs to > be set by someone - runtime, environment, user, application... > As this is a big issue for portability of code, I'd say we should > come up with some sound concept here, but of course that can be > independent of your current work. > >> One of my favorite sob stories here, I've probably told it here, >> is that I have a low end NAS (it won't boot lately..). It runs >> Linux, of course (I said it is low end). I downloaded it source, >> extracted it, xcopied, xcopyied it again incrementally. That >> fails. Because some of the file names start with a dot and on >> Unix, that means they are hidden and cannot be unhidden.. > > `Hidden' on Unix usually only means that files are not shown with > a simple `ls'. There's nothing special in the system to treat dot- > files > different from others as far as I know. > >> So this whole "hidden" thing is not portable, just as colons in >> paths are not portable, but they work just fine if you stay on >> one system... > >> Let me get M3Path to where I want it, and repair the Unix colon >> behavior, and see about rewriting the "cleanup" code... as long >> as folks are happy with how it ends up, I'm not sure I want to >> puruse it much more. There are much bigger fish... > > OK, I can understand that you just want to finishd your current work. > >> Oh, I already have code on my system so that when we read ROOT, >> CM3_INSTALL, CM3_ROOT from the command line and/or environment, >> those paths get "fixed up" -- slashes reversed. That should help >> a lot here, without much pollution.. > > It should help, but it also needs to be tested on different platforms. > >> One thing I'm not sure about is the treatment of backward slashes >> equivalent to forward slashes on Posix. >> Maybe better just to do that fixup upon a few certain inputs. And >> have Win32 use either, but Posix only forward. >> It's "harmless" but loose. > > Yes, I'd be rather conservative there, too. > >> There this general problem of "user input" vs. "internal, >> strongly typed, analyzed, rule-following" data. >> As well as then presenting the internal data back to the user in >> the form he expected. >> >> It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo >> but when an error message is reported, in case I am going to copy/ >> paste the paths in it to file.open, it should be back with >> backward slashes. This is not simple. You could maintain two >> parallel representations as you muck with the path. Not great. >> You could "characterize" the form of the user in put (which >> slash directory), keep that around, it's just one bit, and use it >> to guide the later presentation... > > One internal, abstract representation of the data, and two or more > views on it (getPosixPath, getWindowsPath, ...) come to mind here. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 19:09:13 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 19:09:13 +0100 Subject: [M3devel] Building minimal and fresh cm3... In-Reply-To: <1203610084.11244.14.camel@hias.m3w.org> References: <1203610084.11244.14.camel@hias.m3w.org> Message-ID: <20080221190913.mzepfpxvls0c4g44@mail.elegosoft.com> Why not just use scripts/make-bin-dist-min.sh? This is run nightly for all tested platforms, too. If you could add a switch to produce an rpm archive on Linux, that could be done automatically, too. Olaf Quoting Dragi?a Duri? : > I am trying to make minimal binary rpm for latest cm3. I am creating > it's contents with: > > *** copied and edited cm3.cfg for new root. Set M3CONFIG to point to it. > > *** copied cm3cg into new .../bin (Do I need ONLY these three files for > bootstrap only??? cm3, cm3cg and cm3.cfg) > > *** checked out yesterday's head > > *** did ./scripts/do-cm3-std.sh buildship > > At this moment, I would like to bootstrap new compiler. I see there's > "sysutils" package now, so probably I have to modify former list of > packages, and I did it so I typed: > > *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker > m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; > cm3 -ship) > > All went well, except I had to add m3objfile (and later m3back) because > of: > > "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/m3makefile", > line 24: quake runtime error: unable to open > "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading > > I supposse I also have to build m3cc so I have latest cm3cg? > > *** did ./scripts/do-cm3-std.sh buildship so all is build with latest > cm3. > > Is this all I need to have brand new hierarchy I can pack into rpm and > distribute? > > dd > > -- > Dragi?a Duri? > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 21:16:41 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 21 Feb 2008 15:16:41 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: <47BD95D6.1E75.00D7.1@scires.com> I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy >>> Jay 2/21/2008 7:56 AM >>> "Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix. And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong. That is, "cleanup" of a/./b to a/b, a/../b to b. Incorrect in the face of links. But still general purpose if people want it. The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target". This is specially just changing slashes around. It does not deal with "drive letters". It deals with "file types". This is an area that probably does not belong in libm3. "types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib. There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix. Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward. It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data. As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo but when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: mika at async.caltech.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > I have some ideas here that I am pretty certain WILL be acceptable. > > But I'd like to know if the current behavior really isn't. > > > > The ideas are: > > 1) > > (* A well designed approach might look like this, however how do > > we determine the target behavior? > > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END; > > SepKind_t = { Unix, Win, Winx }; > > > > CONST > > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; > > *) > > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix". > > > > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial. > > > > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more. > > Like into m3quake (QPath?) or m3middle (M3Path?). > > > > However I worry about the effect on source control history. > > Advise? > > > > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3. > > I agree that we should have one central abstraction of the pathanme > type. What about pushing it further into libm3/.../Pathname? This would > need carefully checking of compatibility of course. Also I wouldn't > like to see variables exposed in such a module; we should use > functions or procedures for everything there. > > Do you see any problem in providing such a globally unique and > compatible abstraction? > > Could you provide a complete (documented) Pathname module that could be > discussed on this list and tested by everybody interested? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Shed those extra pounds with MSN and The Biggest Loser! Learn more. ( http://biggestloser.msn.com/ ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 06:26:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 05:26:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47BD95D6.1E75.00D7.1@scires.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <47BD95D6.1E75.00D7.1@scires.com> Message-ID: I made one change to the Win32 Pathname implementation and that will be it unless there is more thought and consensus. That change is to treat forward and backward slashes "the same", essentially as the underlying layer (kernel32.dll) already does. Is this not ok? You do all realize that Win32 /largely/ accepts forward slashes just fine, right? There are some exceptions.It is the functions in kernel32.dll that accept them. Not necessarily shlwapi.dll and definitely not the file.open dialogs. There is way in which forward slashes don't work. I can explain later. M3Path currently has "strange" behavior on Posix for colon and backward slash. I have the colon and I think backslash parts fixed on my machine. Essentially I have: CONST Slash = '/'; VAR (* formerly CONST *) Backslash := '\000'; (* initial value for Posix *) Colon := '\000'; (* initial value for Posix *)IsDirSep(ch) return (ch = Slash OR ch = Backslash) IsSep(ch) return (ch = Slash OR ch = Backslash OR ch = Colon) I do actually worry about nulls in strings sometimes but nobody else seems to. Allowing nulls is an advantage of approaches that keep a length separate. I believe the previous code was already sleazy this way. BEGIN (* Module initialization *) LocalSlash := Text.GetChar ( Pathname.Join ("a", "b"), 1); IF LocalSlash = '\\' THEN BackSlash := '\\'; Colon := ':'; ELSE OS := Env.Get ("OS"); IF OS # NIL AND Text.Equal (OS, "Windows_NT") THEN same thing END END; The point being to accept colons and backslashes on NT386 and Cygwin. One thing I don't quite get and people here probably don't realize is that the compiler tries to traffice in both host and target paths. It's not just about portabily using the host system, as people are so happy with the existing libm3 for. Now, I'm not sure what the point is, and I am skeptical it even works. I think the point might be for when bootstrapping, maybe to use the .M3SHIP files on the target. This need to deal with more than just the host system's paths MIGHT be something for libm3. Some way to "sniff" a path for its type, and then deal with it using the interfaces. This is probably easily done just be exposing PathPosix and PathWin32, which implement themselves and Path. The interface could just be Path to start, plus an explicit "create" function to get started, and maybe a "get" function to get the string as a regular string. A function "FixUp" or specifically "CleanupSlashes" that changes runs of slashes to single slashes, and "RemoveSingleDots" and "RemoveDoubleDots" might be ok to provide but you'd have to call them manually. Gotta go, - Jay Date: Thu, 21 Feb 2008 15:16:41 -0500From: rcoleburn at scires.comTo: wagner at elegosoft.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy>>> Jay 2/21/2008 7:56 AM >>>"Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix.And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong.That is, "cleanup" of a/./b to a/b, a/../b to b.Incorrect in the face of links.But still general purpose if people want it.The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target".This is specially just changing slashes around.It does not deal with "drive letters". It deals with "file types".This is an area that probably does not belong in libm3."types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib.There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix.Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward.It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data.As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foobut when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 08:37:37 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 07:37:37 +0000 Subject: [M3devel] some vagaries of Win32 path semantics (and some Mac) Message-ID: some vagaries of Win32 path semantics (and some Mac) You can learn about this stuff by looking at the NT namespace with winobj.And/or watching calls to NtCreateFile in a debugger.And/or with filemon.And/or reading the documentation for driver writers.And/or various documentation about the NT kernel interface.And/or experimenting with cmd (assuming cmd isn't doing the wierd stuff). This is about kernel32.dll for now. When using 8 bit characters, the length limit is 260 characters.Whether or not that includes the terminal zero is not clear. When using 16 bit characters, the "default" limit is also 260 characters. MS-DOS limit is 64 or maybe 128 characters, so this is progress. (!) Unix limit I think is usually around 1024. That's still pretty lame imho, just a little less lame. The actual Windows limit is 32K which seems pretty ok to me, though 16bit limits are surprising. The limit on INDIVIDUAL PATH ELEMENTS, as dictated by FindFirstFile/FindNextFileis also 260 characters. But again, for individual path elements.I haven't tried exceeding that. The creation paths don't clearly havethis limit. It is worth experimenting with. Ignoring Windows 9x, everything is built on top of the NT kernel.Most interesting here is NtCreateFile. At the kernel level, "relative opens" are allowed.All the various "name" or "path" based functions don't just take a string,they take an OBJECT_ATTRIBUTES.This is mainly flags, an optional parent handle, and a unicode string.The length of the unicode string is stored in an unsigned shortrepresenting a number of bytes. So the limit is around 32,767.One of the flags controls case sensitivity, for example, at least somewhat.I don't know what happens if you try to be case sensitive on FAT, for example. NTFS allows volumes to be mounted in empty directories.I assume such a volume could be FAT, so even if c:\ is NTFS and capableof case sensitivity, c:\foo might not be. If you are doing a non-relative open at the NT level, there is no working directoryor relative paths or such. There is basically just full paths.They don't look quite exactly like anything else.They look like \??\c:\windows\system32\kernel32.dll or \??\unc\machine\share\foo\bar.txt \?? before around NT4 was named \DosDevices.I suspect \?? was an optimization -- making the common case a shorter string.Seems lame but oh well.You can see in driver stuff about setting up symbolic links related to \DosDevices. Yes, NT has symbolic links, in the kernel namespace. At the kernel32.dll level, the documentation clearly exposes something very related.To open paths longer than 260 characters, they say to use the prefixes: \\? or \\?\unc Last I checked, the documentation was a little unclear.What they mean is, to form paths like: \\?\c:\windows\system32\kernel32.dll \\?\unc\machine\share\foo\bar.txt They don't say so, but quick attempts otherwise clearly show, thatthe paths must be full paths. No relative to any "current working directory". An implementation trick should be evident.Just change the second character from \ to ? and you get an NT path. The documentation says \\? "turns off path parsing". Usually all file paths undergo some amount of canonicalization.Forward slashes are changed to backward slashes.Runs of backward slashes are changed to a single slash.Spaces might be removed in some places?Trailing dots also?That is what \\? "turns off". You can see this if you make some CreateFile calls and watch the resulting NtCreateFile.I should put together a demo. Using some hack to intercept the NtCreateFile call. Nearly everything is demoable from the command line.Try this: C:\> mkdir "foo" C:\> mkdir "foo " A subdirectory or file foo already exists. Huh? C:\>mkdir foo. A subdirectory or file foo. already exists. Huh? C:\>mkdir " foo" ok. C:\>mkdir "\\?\c:\foo"C:\>mkdir "\\?\c:\foo " => works rmdir "\\?\c:\foo " C:\>mkdir "\\?\c:\foo." C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\ 02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>rmdir foo.The system cannot find the file specified. Huh? C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\ 02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>mkdir bar. C:\>rmdir bar. C:\>mkdir bar. C:\>rmdir bar huh? mkdir "foo \bar" dir foo expands to "foo " because tab found it but then enterand File Not Found Huh? C:\>mkdir "\\?\c:\foo/" The filename, directory name, or volume label syntax is incorrect. => forward slash not liked C:\>mkdir "c:\foo/" => no error C:\>mkdir "\\?\c:\foo\..\bar" The filename, directory name, or volume label syntax is incorrect. => .. apparently not liked I tried . and that did work. C:\>mkdir c:\foo\..\bar => ok So now I ask -- what is the portable interface and implementation? Most code uses CreateFile and doesn't use \\?. So most code is limited to MAX_PATH and has problems with spaces and dots in some places. These features are all laudable -- allow paths with more than 260 characters and with spaces and dots in more places, if the programmer or user really wants, but this \\? vs. \\? behavior is strange. Trailing spaces in paths tend to be "invisible" in any user interface. (I wonder about tabs too, vertical space, beep, etc.) Note that not everything goes through Win32 usermode CreateFile/kernel32.dll. It is not the one and only path to the file system, but it is overwhelmingly common. Imagine going over the network from a non-Windows client (e.g. Samba) And maybe Services for Unix. shlwapi.dll and even shell32.dll also have a bunch of path/file unitility functions. I've hardly ever used them. I think I tried forward slashes with shlwapi.dll once and no go. In an ntsd/cdb/windbg, try a breakpoint like: bp ntdll!NtCreateFile "!obja poi(@esp+c);g" That will trace the paths to NtCreateFile. It is a low tech filemon.esp is the stack pointer and the object attributes is the third parameter (4*3=c),and !obja prints object attributes. I got bored writing this and maybe didn't finish covering everything, sorry.The thing to do is experiment and see what all changes between CreateFile and NtCreateFile.e.g. paths relative to the current working directory. Oh, also, there is a relative working directory per volume on Windows.There are special environment variables used to store them.Something like the variable =c: has c:'s working directory. C:\>echo %=c:% C:\ C:\>cd foo C:\foo>echo %=c:% C:\foo I only have one volume, so let's make another: C:\foo>subst d: c:\ d: cd bar D:\bar>echo %=d:% D:\bar c: brings me back to c:\foo cd d:\windows changes the working directory of D:, but doesn't bring me there d: now I am on the d: drive You can use /d to cd to change drive and directory at the same time. Cygwin also uses NtCreateFile sometimes. I haven't yet looked at why. NTFS has hardlinks for files, not directories (avoid cycles and I guess adequate for strict Posix?). NTFS on Vista has symlinks I guess for files and directories, not sure. Windows 2000 added a CreateHardLink function. XP has "fsutil hardlink create newlink existingfile" Vista has that and "mklink". Also, on my Mac I can create filenames with forward slashes in them.I have some old files from www.apple.com named like "C/C++ compiler reference".At the command line I think the forward slashes show as colons.Historically on the Mac the colon is path separator, but the "syntax"is different than Posix and Windows. Pathname.i3 documents it. If you read the Mac OS X overviews, you can see Mac OS X is a tremendous mish-mashof similar redundant interfaces and implementations.There are many sets of functions for doing the same thing.There are older functions for example that take 8 bit characters, with limits of255, though usually I believe you do directory relative opens. There are newer APIs that use Unicode and are more opaque. You can have two volumes with the same nameso: :hard disk:foo:bar (at least on Mac OS Classic, not sure about X)can actually name any number of files on Mac, depending on how many disks are named "hard disk". I think what you have to do is enumerate volumes, get their "reference numbers" and do relativeopens from there. so much for string equality meaning two paths reference the same file.Now, granted, if you do two open calls with the same path, I assume it always gets the same one.However, what if in the meantime, more volumes come online?Maybe earlier mounted is earlier opened and consistent? Big mess. (GS/OS on the long dead Apple IIGS also has this forward slash or colon behavior,and I think instead of one current working directory, you could assign a bunch ofthem to numbers. I think file names couldn't start with numbers, or maybe that was ambiguous.) - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 10:00:04 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 09:00:04 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47BD95D6.1E75.00D7.1@scires.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <47BD95D6.1E75.00D7.1@scires.com> Message-ID: As long as \ never occurs, no change. Even if it does..think about it. Before \ was treated as a "regular" character, allowed in paths. It is very unlikely, but not impossible, that \ ever occured, and then it is also unlikely, but not impossible, for the opens with \ to succeed at the next level down. It is more likely to have failed. And then it is very unlikely, but again not impossible, to imagine that code could be depending on this failure. Every single line changed is a change that must be thought through. The implementation is the interface. It is impossible to separate out something smaller and claim it is all other code depends on. For any given change, I can probably come up with code that it broke. If you use more memory, there could be code on the verge of running out of memory that you pushed over the edge. If you expand some limit, there could be code relying on things having smaller limits. If you make something faster, you can expose a race condition, that was already there but tending not to occur. If you make something slower, well, people will just complain. If all I do is add some new functions, well, like memory, I was almost out of disk space or more realistically virtual address space, and now I am. This is a real example. I have seen some code break just because other code grew in size. The code was arguably buggy, but that is besides the point. That doesn't mean that nothing can be changed. You just have to apply reason. So, for the case of backward slashes in Posix paths, is treating them like forward slashes dangerous?This is only in M3Path.m3, that the compiler uses. It is not in the more widely used Pathname module in libm3. I'm going to undo th change and leave it only for "NT386GNU", and I have to double double check that it helps there..well, I know it helps upon input. Imagine you have a text file with some paths and you move it across machines.. Do you: invent a new abstract "path" to store in the file, and write translation on either side ? adopt an existing form and translate on foreign systems ? adopt what looks very nearly like very system's format and be a little careful ? In the form you chose, can you represent anything that is possibly valid? Or do get a bit lazy and disallow some paths, like forward slashes (legal on Mac OS remember) ? A start to an abstract representation is an array of strings, and the strings can have any character, and they have a length stored (don't depend on either space or null termination). a "text" file format becomes less convenient now, because there is no delimiter, you have to store the length. You can still do that as text, it's just less convenient to edit. If you can get away with only storing full paths, that is probably an adequate represenation. If you want some indirection, it is probably useful to decide some "roots", some common prefixes, and factor that out somehow. But this depends on the application. And/Or maybe on the recieving end there is a "search algorithm". I'm just saying, this area is complicated, I know it is complicated. Forward slashes usually do have the same meaning on Win32 as backward slashes AND my goal here to make the system easier to use for anyone, such as myself, using NT386 and NT386GNU. I shouldn't have to set install root and the source root differently between them. Maybe this is just me and I'm lazy and I should suck it up, but if I only have one drive, the ability to use just /cm3 and /dev2/cm3.2 is so close to already being there..and furthermore...if someone is using NT386GNU, but any "normal" Windows editor (ie: not Cygwin vi/emacs), they will want errors printed out with backward slashes so they can copy/paste them into their editor. I guess the "presentation format" should be user configurable. Where "presentation format" could be limited what slash to use. Leaving the user to possibly prefix with c: or /cygdrive/c, which is at least less tedious than changing all the slashes.. That's kind of the thing -- user input and output paths should be more flexible and/or configurable than internal forms. However internal forms should not be warped much or at all to handle this, only input/output functions that mediate between the two. One form caters to various users with various tastes. One form caters to code that is simpler to have just one form and benefits not at all from other forms. The "temptation" though is to make them the same. Anyway, I have this "FixupPath" function that should basically make things this way. I maybe can remove the allowance for the different slashes anywhere else. The output issue is bothering me less right now than the input issue, and even the input issue I had mostly sucked up anyway. I think I was hitting some other problem not related to my own taste/laziness that made me revisit this. As it was, I had already "rewritten" M3Path.m3 twice and then abandoned it, figuring that the original authors had already figured this stuff out and it must already be right..but then I looked at it more and no longer thing that. I don't believe the "naming convention" declared in config files ever did much. All that determined things was the runtime probed slash that Pathname.i3 used. So, making NT386GNU use forward slashes but otherwise Windows naming conventions didn't work. I don't think, correct me if I'm wrong, I don't think libfoo.a vs. foo.lib should be tied with / vs. \. However, I also don't mind switching to libfoo.a for NT386GNU (a target I'm not likely to use once it work..). Maybe I should move on to that. Well, can't leave things as they are anyway... - Jay Date: Thu, 21 Feb 2008 15:16:41 -0500From: rcoleburn at scires.comTo: wagner at elegosoft.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy>>> Jay 2/21/2008 7:56 AM >>>"Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix.And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong.That is, "cleanup" of a/./b to a/b, a/../b to b.Incorrect in the face of links.But still general purpose if people want it.The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target".This is specially just changing slashes around.It does not deal with "drive letters". It deals with "file types".This is an area that probably does not belong in libm3."types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib.There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix.Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward.It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data.As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foobut when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 11:09:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 10:09:41 +0000 Subject: [M3devel] some vagaries of Win32 path semantics (and some Mac) Message-ID: I remembered more complications. Remember that many of these are exposed to Unix via Windows file servers. And of course Mac -- notice that PPC_DARWIN is case sensitive about names, even though that is commonly "wrong". But again, it varies per file system, not "POSIX" vs. "WIN32" ("POSIX" as in Modula-3 source directory/OS_TYPE. I don't know about the standard.) When you are case insensitive, just what are the rules? M3Path handles only a-z. And it doesn't handle Unicode anyway I think, not sure. On NTFS.. C:\>more < $UpcaseAccess is denied. C:\>more < $UpcasexThe system cannot find the file specified. C:\> http://www.ntfs.com/ntfs-system-files.htm There's also a technote on www.apple.com talking about precomposed or non-precomposed and what is canonical. This has something to do with accent characters. And short names are funky. You can turn off the generation of them. I think I sent there here already, but watch this: First, they aren't necessarily shorter than long names. In this case the short name is twice the length of the long name. Short names are always limited to 8.3 though, one dot, and certain characters (ie: not Unicode, I think). C:\>mkdir 1.1.1 C:\>dir /x 1*02/22/2008 02:03 AM 112E5D~1.1 1.1.1 Second, wildcard matching (FindFirstFile/FindNextFile) always includes them: C:\>mkdir foo.bar C:\>mkdir foo.barf C:\>dir *.bar 02/22/2008 02:04 AM foo.bar02/22/2008 02:04 AM foo.barf Huh? C:\>dir /x *bar02/22/2008 02:04 AM foo.bar02/22/2008 02:04 AM FOO~1.BAR foo.barf Oh.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: some vagaries of Win32 path semantics (and some Mac)Date: Fri, 22 Feb 2008 07:37:37 +0000 some vagaries of Win32 path semantics (and some Mac) You can learn about this stuff by looking at the NT namespace with winobj.And/or watching calls to NtCreateFile in a debugger.And/or with filemon.And/or reading the documentation for driver writers.And/or various documentation about the NT kernel interface.And/or experimenting with cmd (assuming cmd isn't doing the wierd stuff).This is about kernel32.dll for now.When using 8 bit characters, the length limit is 260 characters.Whether or not that includes the terminal zero is not clear.When using 16 bit characters, the "default" limit is also 260 characters. MS-DOS limit is 64 or maybe 128 characters, so this is progress. (!) Unix limit I think is usually around 1024. That's still pretty lame imho, just a little less lame. The actual Windows limit is 32K which seems pretty ok to me, though 16bit limits are surprising.The limit on INDIVIDUAL PATH ELEMENTS, as dictated by FindFirstFile/FindNextFileis also 260 characters. But again, for individual path elements.I haven't tried exceeding that. The creation paths don't clearly havethis limit. It is worth experimenting with.Ignoring Windows 9x, everything is built on top of the NT kernel.Most interesting here is NtCreateFile.At the kernel level, "relative opens" are allowed.All the various "name" or "path" based functions don't just take a string,they take an OBJECT_ATTRIBUTES.This is mainly flags, an optional parent handle, and a unicode string.The length of the unicode string is stored in an unsigned shortrepresenting a number of bytes. So the limit is around 32,767.One of the flags controls case sensitivity, for example, at least somewhat.I don't know what happens if you try to be case sensitive on FAT, for example.NTFS allows volumes to be mounted in empty directories.I assume such a volume could be FAT, so even if c:\ is NTFS and capableof case sensitivity, c:\foo might not be.If you are doing a non-relative open at the NT level, there is no working directoryor relative paths or such. There is basically just full paths.They don't look quite exactly like anything else.They look like \??\c:\windows\system32\kernel32.dll or \??\unc\machine\share\foo\bar.txt \?? before around NT4 was named \DosDevices.I suspect \?? was an optimization -- making the common case a shorter string.Seems lame but oh well.You can see in driver stuff about setting up symbolic links related to \DosDevices.Yes, NT has symbolic links, in the kernel namespace.At the kernel32.dll level, the documentation clearly exposes something very related.To open paths longer than 260 characters, they say to use the prefixes: \\? or \\?\uncLast I checked, the documentation was a little unclear.What they mean is, to form paths like: \\?\c:\windows\system32\kernel32.dll \\?\unc\machine\share\foo\bar.txt They don't say so, but quick attempts otherwise clearly show, thatthe paths must be full paths. No relative to any "current working directory".An implementation trick should be evident.Just change the second character from \ to ? and you get an NT path.The documentation says \\? "turns off path parsing".Usually all file paths undergo some amount of canonicalization.Forward slashes are changed to backward slashes.Runs of backward slashes are changed to a single slash.Spaces might be removed in some places?Trailing dots also?That is what \\? "turns off".You can see this if you make some CreateFile calls and watch the resulting NtCreateFile.I should put together a demo. Using some hack to intercept the NtCreateFile call.Nearly everything is demoable from the command line.Try this: C:\> mkdir "foo" C:\> mkdir "foo " A subdirectory or file foo already exists. Huh? C:\>mkdir foo. A subdirectory or file foo. already exists. Huh? C:\>mkdir " foo"ok.C:\>mkdir "\\?\c:\foo"C:\>mkdir "\\?\c:\foo " => works rmdir "\\?\c:\foo "C:\>mkdir "\\?\c:\foo."C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes freeC:\>rmdir foo.The system cannot find the file specified.Huh?C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>mkdir bar. C:\>rmdir bar. C:\>mkdir bar. C:\>rmdir bar huh? mkdir "foo \bar" dir foo expands to "foo " because tab found it but then enterand File Not Found Huh? C:\>mkdir "\\?\c:\foo/" The filename, directory name, or volume label syntax is incorrect. => forward slash not liked C:\>mkdir "c:\foo/" => no error C:\>mkdir "\\?\c:\foo\..\bar" The filename, directory name, or volume label syntax is incorrect. => .. apparently not liked I tried . and that did work. C:\>mkdir c:\foo\..\bar => ok So now I ask -- what is the portable interface and implementation? Most code uses CreateFile and doesn't use \\?. So most code is limited to MAX_PATH and has problems with spaces and dots in some places. These features are all laudable -- allow paths with more than 260 characters and with spaces and dots in more places, if the programmer or user really wants, but this \\? vs. \\? behavior is strange. Trailing spaces in paths tend to be "invisible" in any user interface.(I wonder about tabs too, vertical space, beep, etc.) Note that not everything goes through Win32 usermode CreateFile/kernel32.dll. It is not the one and only path to the file system, but it is overwhelmingly common. Imagine going over the network from a non-Windows client (e.g. Samba) And maybe Services for Unix. shlwapi.dll and even shell32.dll also have a bunch of path/file unitility functions. I've hardly ever used them. I think I tried forward slashes with shlwapi.dll once and no go.In an ntsd/cdb/windbg, try a breakpoint like: bp ntdll!NtCreateFile "!obja poi(@esp+c);g" That will trace the paths to NtCreateFile. It is a low tech filemon.esp is the stack pointer and the object attributes is the third parameter (4*3=c),and !obja prints object attributes.I got bored writing this and maybe didn't finish covering everything, sorry.The thing to do is experiment and see what all changes between CreateFile and NtCreateFile.e.g. paths relative to the current working directory.Oh, also, there is a relative working directory per volume on Windows.There are special environment variables used to store them.Something like the variable =c: has c:'s working directory. C:\>echo %=c:% C:\ C:\>cd foo C:\foo>echo %=c:% C:\foo I only have one volume, so let's make another: C:\foo>subst d: c:\ d: cd bar D:\bar>echo %=d:% D:\bar c: brings me back to c:\foo cd d:\windows changes the working directory of D:, but doesn't bring me there d: now I am on the d: drive You can use /d to cd to change drive and directory at the same time.Cygwin also uses NtCreateFile sometimes. I haven't yet looked at why. NTFS has hardlinks for files, not directories (avoid cycles and I guess adequate for strict Posix?). NTFS on Vista has symlinks I guess for files and directories, not sure. Windows 2000 added a CreateHardLink function. XP has "fsutil hardlink create newlink existingfile" Vista has that and "mklink". Also, on my Mac I can create filenames with forward slashes in them.I have some old files from www.apple.com named like "C/C++ compiler reference".At the command line I think the forward slashes show as colons.Historically on the Mac the colon is path separator, but the "syntax"is different than Posix and Windows. Pathname.i3 documents it.If you read the Mac OS X overviews, you can see Mac OS X is a tremendous mish-mashof similar redundant interfaces and implementations.There are many sets of functions for doing the same thing.There are older functions for example that take 8 bit characters, with limits of255, though usually I believe you do directory relative opens.There are newer APIs that use Unicode and are more opaque.You can have two volumes with the same nameso: :hard disk:foo:bar (at least on Mac OS Classic, not sure about X)can actually name any number of files on Mac, depending on how many disks are named "hard disk".I think what you have to do is enumerate volumes, get their "reference numbers" and do relativeopens from there.so much for string equality meaning two paths reference the same file.Now, granted, if you do two open calls with the same path, I assume it always gets the same one.However, what if in the meantime, more volumes come online?Maybe earlier mounted is earlier opened and consistent? Big mess.(GS/OS on the long dead Apple IIGS also has this forward slash or colon behavior,and I think instead of one current working directory, you could assign a bunch ofthem to numbers. I think file names couldn't start with numbers, or maybe that was ambiguous.) - Jay Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 11:41:54 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 10:41:54 +0000 Subject: [M3devel] some Cygwin path vagaries In-Reply-To: <20080222111045.2qhhuhoqo0cgo4sk@mail.elegosoft.com> References: <20080222104722.lh7jgctc68kk4wso@mail.elegosoft.com> <20080222111045.2qhhuhoqo0cgo4sk@mail.elegosoft.com> Message-ID: Well this surprised me. Cygwin fopen accepts all of /cygdrive/c/1.txt \cygdrive\c\1.txt c:\1.txt c:/1.txt They all mean the same (well, actually, that I just assume, I'm able to fopen each) c:1.txt didn't work (it would work in Win32) I thought I'd seen Cygwin not accepting Win32 paths. Geez, maybe this makes things easier.. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 22 16:24:08 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:24:08 -0600 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] Message-ID: <47BEE918.1060908@wichita.edu> This didn't appear to come through to the list the first time: -------- Original Message -------- Subject: Re: [M3devel] <*LAZYALIGN*> Date: Mon, 18 Feb 2008 20:11:17 -0600 From: Rodney M. Bates To: Randy Coleburn CC: m3devel at elegosoft.com References: <47AF72B5.2080308 at wichita.edu> <47B1168F.8020302 at wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236 at darko.org> <47B4C70D.4010408 at wichita.edu> <7323567C-7632-4040-B858-47B8124759DC at cs.purdue.edu> <47B50EDF.8060807 at wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843 at cs.purdue.edu> <47B5FB13.7070407 at wichita.edu> <20080215223205.t9a01icx4okgco0o at mail.elegosoft.com> <47B60CE0.8050506 at wichita.edu> <47B9644F.1E75.00D7.1 at scires.com> Just to clarify: I don't believe anything existing has to break. The worst scenario I can see is that you would have to either simultaneously upgrade the compiler, libm3, and libm3core (or else none of these) before recompiling & linking any code that reads or writes pickles. If libm3 and libm3core are dynamically linked in at runtime, you would have to recompile with an upgraded compiler at the same time as installing the upgraded dynamic libraries. Existing pickle files would not change. Also, mixtures of programs thus recompiled & linked and programs not recompiled/linked could exchange pickle files. Anything that (un)pickles records or objects that are LAZYALIGN would need the upgrade to work, but such programs are already broken. Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add support > for something that is rarely used. > Regards, > Randy > -- ------------------------------------------------------------- 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 -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 16:35:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:35:15 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> Message-ID: <47BEEBB3.6000800@wichita.edu> Darko wrote: > There wouldn't be any explicit expression. in the source, but there > would be a flag in Target.i3 for turning it off and on for different > platforms. > > Although the details may be a bit off, the principal is this: > > before byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 32 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) ^If the compiler's alignment rules are not lazy, then this violates a language rule and should not compile. From 2.2.5, Packed types: "...variables of type T that occur in records, objects, or arrays will occupy exactly n bits and be packed adjacent to the preceding field or element." To get the padding between a and b, you would have to either put it in with an explicit pad field, or remove the BITS 32 from the type of b. > c: BITS 16 FOR 0..65000; (* takes 32 bits *) > END; > > after byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 8 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 16 bits *) > END; > > > On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > >> Thanks for the explanation! How does one express the alignment you >> support? >> >> It does sound like <*LAZYALIGN*> can go away. >> >> On Feb 18, 2008, at 8:44 PM, Darko wrote: >> >>> Actually rather than compilain rather grumpily, maybe I can just >>> make the >>> changes required to RTTipe and do the work to reomve the pragma. I can >>> work with Randy to ensure it doesn't break pickles, there is no >>> reason why >>> it should. >>> >>> On tha subject Randy, I assume pickles encode the number of BITS FOR >>> for a field? If not it should. >>> >>> >>>> We seem to be going through these same point several times. I'm not >>>> sure >>>> what the difficulty is, I'm just repeating myself. >>>> >>>> Keep in mind this applies *only* to packed structures, ie BIT FOR >>>> or bit >>>> fields. >>>> >>>> The change I put in libralised the *M3* alignment rules so that >>>> BITS FOR >>>> fields in structures would align on byte boundries if possible >>>> instead of >>>> restricting them to word alignment generally. GCC happily generates >>>> code >>>> for this. There may be restrictions in GCC's C as to how you can >>>> arrange >>>> bit fields but I don't see what they have to do with M3. >>>> >>>> This is absolutely essentail for using the native APIs on Mac OS X >>>> and its >>>> removal would make M3 pointless for use on the Mac, at least more me. >>>> >>>> This should be the default behviour. If you are using BITS FOR it's >>>> becuase you want to arrange the fields in a record in particular >>>> way. Why >>>> then arbitrarliy pad out the fields? If performance is an issue, >>>> the user >>>> should be using appropriate field bit sizes. The implementation >>>> rule for >>>> BITS FOR in M3 is implementation dependent, there are no language >>>> issues. >>>> >>>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>>> created and had nothing to do with me. I diagreed with it and never >>>> used >>>> it in the version of the compiler I ran. I support its removal. >>>> >>>> >>>> >>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>> >>>>>> The alignment behaviour is absolutely crucial to programming >>>>>> natively in Mac OS X and should be kept. I have a great need for it. >>>>>> >>>>>> The PRGAMA is of no use and can be removed. >>>>>> >>>>>> Does anyone have any objections to making this alignment behaviour >>>>>> standard? >>>>> >>>>> >>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>>> the standard gcc-backend alignment? Perhaps I don't understand what >>>>> it is you are doing or trying to do. Again, please remind me what it >>>>> is that LAZYALIGN does and why it is needed. >>>>> >>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>> >>>>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>>> argue to abandon it. >>>>>>> >>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>> >>>>>>>> I use pickles extensively and they are used also by network >>>>>>>> objects. >>>>>>>> I've never used LAZYALIGN. >>>>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>>>> support for something that is rarely used. >>>>>>>> Regards, >>>>>>>> Randy >>>>>>>> >>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>> >>>>>>>> PM >>> >>>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>>>> requiring existing pickle files to be regenerated and/or existing >>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>> >>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>> pickles >>>>>>>> or compiled code were invalidated by a change? >>>>>>>> >>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>> variables of that type. >>>>>>>> >>>>>>>> Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>> >>>>>>>> LAZYALIGN. >>>>>>>> >>>>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>>>> >>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>> >>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>>> >>>>>>>> BITSIZE, >>>>>>>> >>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>> >>>>>>>> executing >>>>>>>> >>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>> >>>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>>> >>>>>>>> both as >>>>>>>> >>>>>>>>>> it is on the reading machine and as it was on the machine that >>>>>>>> >>>>>>>> wrote >>>>>>>> >>>>>>>>>> the pickle. The type description that the compiler generates is >>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>> >>>>>>>> field >>>>>>>> >>>>>>>>>> types (which are either recursive type descriptions or builtin >>>>>>>> >>>>>>>> types). >>>>>>>> >>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>> >>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>> >>>>>>>> machine >>>>>>>> >>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>> >>>>>>>> description and >>>>>>>> >>>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>>> >>>>>>>> as they >>>>>>>> >>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>> >>>>>>>> the latter, >>>>>>>> >>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>> >>>>>>>> stored in the >>>>>>>> >>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>> >>>>>>>> techniques >>>>>>>> >>>>>>>>>> like >>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>> >>>>>>>> m3core, and >>>>>>>> >>>>>>>>>> called by Pickle code. >>>>>>>>>> >>>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>>> >>>>>>>> layout >>>>>>>> >>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>> >>>>>>>> involve >>>>>>>> >>>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>>> >>>>>>>> data >>>>>>>> >>>>>>>>>> structure and code organization. It will be obvious what kind >>>>>>>> >>>>>>>> of bit >>>>>>>> >>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>> >>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>> >>>>>>>> comparing the >>>>>>>> >>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>> >>>>>>>> compiler. The >>>>>>>> >>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>> >>>>>>>>>> Note that all this is required even without any packing of >>>>>>>> >>>>>>>> small fields >>>>>>>> >>>>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>>>> >>>>>>>> on a >>>>>>>> >>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>> >>>>>>>>>> Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Rodney, >>>>>>>>>>> >>>>>>>>>>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>> >>>>>>>> anyway. >>>>>>>> >>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>> >>>>>>>> figure >>>>>>>> >>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>> >>>>>>>> INTEGER is >>>>>>>> >>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I missing >>>>>>>>>>> something? >>>>>>>>>>> >>>>>>>>>>> -- Tony >>>>>>>>>>> >>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>>> >>>>>>>> help with? >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>> >>>>>>>> recently) >>>>>>>> >>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>> >>>>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 16:40:44 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:40:44 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> References: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> Message-ID: <47BEECFC.8060308@wichita.edu> I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable for another, more serious reason, namely, that the byte ordering of type signatures in the files is different. I think this can be fixed by making pickle code try either byte ordering, without invalidating any existing pickle files. There would be a very remote chance of a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. Mika Nystrom wrote: > Ugh!!! I am still using compilers that are almost ten years old > on ALL my systems just because I need to share pickles between them > and CM3 has a different TEXT format from my ancient PM3. Tony > thinks there's a workaround with specials but I haven't had a chance > to get to it yet... > > > -- ------------------------------------------------------------- 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 darko at darko.org Fri Feb 22 16:33:47 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 02:33:47 +1100 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BEE918.1060908@wichita.edu> References: <47BEE918.1060908@wichita.edu> Message-ID: <1E474378-253C-4484-813B-A747EF28051B@darko.org> I don't think breaking pickles is at issue at all since the alignment issues don't change the meaning of a type, only its layout in memory on a particular platform, akin to endian issues. On 23/02/2008, at 2:24 AM, Rodney M. Bates wrote: > This didn't appear to come through to the list the first time: > > -------- Original Message -------- > Subject: Re: [M3devel] <*LAZYALIGN*> > Date: Mon, 18 Feb 2008 20:11:17 -0600 > From: Rodney M. Bates > To: Randy Coleburn > CC: m3devel at elegosoft.com > References: <47AF72B5.2080308 at wichita.edu> > <47B1168F.8020302 at wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236 at darko.org > > <47B4C70D.4010408 at wichita.edu> <7323567C-7632-4040-B858-47B8124759DC at cs.purdue.edu > > <47B50EDF.8060807 at wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843 at cs.purdue.edu > > <47B5FB13.7070407 at wichita.edu > > <20080215223205.t9a01icx4okgco0o at mail.elegosoft.com> <47B60CE0.8050506 at wichita.edu > > <47B9644F.1E75.00D7.1 at scires.com> > > Just to clarify: I don't believe anything existing has to break. The > worst scenario I can see is that you would have to either > simultaneously > upgrade the compiler, libm3, and libm3core (or else none of these) > before > recompiling & linking any code that reads or writes pickles. If > libm3 and > libm3core are dynamically linked in at runtime, you would have to > recompile > with an upgraded compiler at the same time as installing the upgraded > dynamic libraries. > > Existing pickle files would not change. Also, mixtures of programs > thus > recompiled & linked and programs not recompiled/linked could > exchange pickle > files. > > Anything that (un)pickles records or objects that are LAZYALIGN > would need > the upgrade to work, but such programs are already broken. > > Randy Coleburn wrote: >> I use pickles extensively and they are used also by network objects. >> I've never used LAZYALIGN. >> My vote is that we don't break something (pickles/netobj) to add >> support for something that is rarely used. >> Regards, >> Randy > -- > ------------------------------------------------------------- > 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 > > > -- > ------------------------------------------------------------- > 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 darko at darko.org Fri Feb 22 16:38:29 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 02:38:29 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BEEBB3.6000800@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> Message-ID: I think you may be reading that definition too literally. Any processor is going to data alignment rules so 'adjacent' is subject to what can be implemented on the processor. The problem I have is that the existing code doesn't pack to the limits of the processor, but to some arbitrary alignment. Thus my comment about viewing so-called lazy alignment as a fix to an alignment bug. On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > > > Darko wrote: >> There wouldn't be any explicit expression. in the source, but >> there would be a flag in Target.i3 for turning it off and on for >> different platforms. >> Although the details may be a bit off, the principal is this: >> before byte alignment change: >> RECORD >> a: BITS 8 FOR 0..255; (* takes 32 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) > > ^If the compiler's alignment rules are not lazy, then this violates > a language rule and should not compile. From 2.2.5, Packed types: > > "...variables of type T that occur in records, objects, or arrays will > occupy exactly n bits and be packed adjacent to the preceding field or > element." > > To get the padding between a and b, you would have to either put it in > with an explicit pad field, or remove the BITS 32 from the type of b. > >> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >> END; >> after byte alignment change: >> RECORD >> a: BITS 8 FOR 0..255; (* takes 8 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >> END; >> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >>> Thanks for the explanation! How does one express the alignment >>> you support? >>> >>> It does sound like <*LAZYALIGN*> can go away. >>> >>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>> >>>> Actually rather than compilain rather grumpily, maybe I can just >>>> make the >>>> changes required to RTTipe and do the work to reomve the pragma. >>>> I can >>>> work with Randy to ensure it doesn't break pickles, there is no >>>> reason why >>>> it should. >>>> >>>> On tha subject Randy, I assume pickles encode the number of BITS >>>> FOR >>>> for a field? If not it should. >>>> >>>> >>>>> We seem to be going through these same point several times. I'm >>>>> not sure >>>>> what the difficulty is, I'm just repeating myself. >>>>> >>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>> FOR or bit >>>>> fields. >>>>> >>>>> The change I put in libralised the *M3* alignment rules so that >>>>> BITS FOR >>>>> fields in structures would align on byte boundries if possible >>>>> instead of >>>>> restricting them to word alignment generally. GCC happily >>>>> generates code >>>>> for this. There may be restrictions in GCC's C as to how you >>>>> can arrange >>>>> bit fields but I don't see what they have to do with M3. >>>>> >>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>> X and its >>>>> removal would make M3 pointless for use on the Mac, at least >>>>> more me. >>>>> >>>>> This should be the default behviour. If you are using BITS FOR >>>>> it's >>>>> becuase you want to arrange the fields in a record in >>>>> particular way. Why >>>>> then arbitrarliy pad out the fields? If performance is an >>>>> issue, the user >>>>> should be using appropriate field bit sizes. The implementation >>>>> rule for >>>>> BITS FOR in M3 is implementation dependent, there are no >>>>> language issues. >>>>> >>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>> Olaf >>>>> created and had nothing to do with me. I diagreed with it and >>>>> never used >>>>> it in the version of the compiler I ran. I support its removal. >>>>> >>>>> >>>>> >>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>> >>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>> for it. >>>>>>> >>>>>>> The PRGAMA is of no use and can be removed. >>>>>>> >>>>>>> Does anyone have any objections to making this alignment >>>>>>> behaviour >>>>>>> standard? >>>>>> >>>>>> >>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>> with >>>>>> the standard gcc-backend alignment? Perhaps I don't >>>>>> understand what >>>>>> it is you are doing or trying to do. Again, please remind me >>>>>> what it >>>>>> is that LAZYALIGN does and why it is needed. >>>>>> >>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>> >>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>> with >>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>> would >>>>>>>> argue to abandon it. >>>>>>>> >>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>> >>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>> objects. >>>>>>>>> I've never used LAZYALIGN. >>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>> add >>>>>>>>> support for something that is rarely used. >>>>>>>>> Regards, >>>>>>>>> Randy >>>>>>>>> >>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>> >>>>>>>>> PM >>> >>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>> to >>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>> without >>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>> existing >>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>> >>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>> >>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>> variables of that type. >>>>>>>>> >>>>>>>>> Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>> the >>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>> >>>>>>>>> LAZYALIGN. >>>>>>>>> >>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>> pickles. >>>>>>>>>> >>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>> >>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>> Using >>>>>>>>> >>>>>>>>> BITSIZE, >>>>>>>>> >>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>> >>>>>>>>> executing >>>>>>>>> >>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>> >>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>> type >>>>>>>>> >>>>>>>>> both as >>>>>>>>> >>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>> that >>>>>>>>> >>>>>>>>> wrote >>>>>>>>> >>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>> generates is >>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>> >>>>>>>>> field >>>>>>>>> >>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>> builtin >>>>>>>>> >>>>>>>>> types). >>>>>>>>> >>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>> >>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>> >>>>>>>>> machine >>>>>>>>> >>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>> >>>>>>>>> description and >>>>>>>>> >>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>> both >>>>>>>>> >>>>>>>>> as they >>>>>>>>> >>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>> >>>>>>>>> the latter, >>>>>>>>> >>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>> >>>>>>>>> stored in the >>>>>>>>> >>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>> >>>>>>>>> techniques >>>>>>>>> >>>>>>>>>>> like >>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>> >>>>>>>>> m3core, and >>>>>>>>> >>>>>>>>>>> called by Pickle code. >>>>>>>>>>> >>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>> compiler's >>>>>>>>> >>>>>>>>> layout >>>>>>>>> >>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>> >>>>>>>>> involve >>>>>>>>> >>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>> different >>>>>>>>> >>>>>>>>> data >>>>>>>>> >>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>> kind >>>>>>>>> >>>>>>>>> of bit >>>>>>>>> >>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>> >>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>> >>>>>>>>> comparing the >>>>>>>>> >>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>> >>>>>>>>> compiler. The >>>>>>>>> >>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>> >>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>> >>>>>>>>> small fields >>>>>>>>> >>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>> pickled >>>>>>>>> >>>>>>>>> on a >>>>>>>>> >>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Rodney, >>>>>>>>>>>> >>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>> RTPacking? I >>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>> >>>>>>>>> anyway. >>>>>>>>> >>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>> >>>>>>>>> figure >>>>>>>>> >>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>> >>>>>>>>> INTEGER is >>>>>>>>> >>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>> missing >>>>>>>>>>>> something? >>>>>>>>>>>> >>>>>>>>>>>> -- Tony >>>>>>>>>>>> >>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>> can >>>>>>>>> >>>>>>>>> help with? >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>> type >>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>> >>>>>>>>> recently) >>>>>>>>> >>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Fri Feb 22 22:19:15 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 22 Feb 2008 13:19:15 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> Message-ID: <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> Oh I should be clear on what I mean, exactly, when I say things like that. Pickles "version 1", what was in SRC M3 and is in PM3, were never from what I understand completely implemented? For one thing, they didn't support endian-switching. A gentleman with a Scottish name that eludes me at the moment came out with "Pickles version 2", which do the endianness-switching, among other things. My "PM3" includes a lot of things from newer M3s, such as this Pickles version 2. I really am not enamored with my ancient PM3. I just need something that works reliably on Cygwin *and* FreeBSD (which it does). So adding the odd CM3 library to it is no big deal. But the TEXT issue is so deeply embedded in the compiler and runtime that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or vice versa. I am almost certain I have tested interchanging pickles between my PM3 code and some CM3 code and verified that it did work as long as there were no TEXTs involved. (It was a couple of years ago I did this; I think I spammed m3devel about it then too.) Mika "Rodney M. Bates" writes: >I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable >for another, more serious reason, namely, that the byte ordering of type >signatures in the files is different. > >I think this can be fixed by making pickle code try either byte ordering, without >invalidating any existing pickle files. There would be a very remote chance of >a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. > >Mika Nystrom wrote: >> Ugh!!! I am still using compilers that are almost ten years old >> on ALL my systems just because I need to share pickles between them >> and CM3 has a different TEXT format from my ancient PM3. Tony >> thinks there's a workaround with specials but I haven't had a chance >> to get to it yet... >> >> >> >-- >------------------------------------------------------------- >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 mika at async.caltech.edu Fri Feb 22 22:20:52 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 22 Feb 2008 13:20:52 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Sat, 23 Feb 2008 02:38:29 +1100." Message-ID: <200802222120.m1MLKqbK010997@camembert.async.caltech.edu> Hmm, can't you always write code to force whatever bit pattern you like, if you absolutely insist on it? One could read the specification that way too. Mika Darko writes: >I think you may be reading that definition too literally. Any >processor is going to data alignment rules so 'adjacent' is subject to >what can be implemented on the processor. The problem I have is that >the existing code doesn't pack to the limits of the processor, but to >some arbitrary alignment. Thus my comment about viewing so-called lazy >alignment as a fix to an alignment bug. > > >On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > >> >> >> Darko wrote: >>> There wouldn't be any explicit expression. in the source, but >>> there would be a flag in Target.i3 for turning it off and on for >>> different platforms. >>> Although the details may be a bit off, the principal is this: >>> before byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> >> ^If the compiler's alignment rules are not lazy, then this violates >> a language rule and should not compile. From 2.2.5, Packed types: >> >> "...variables of type T that occur in records, objects, or arrays will >> occupy exactly n bits and be packed adjacent to the preceding field or >> element." >> >> To get the padding between a and b, you would have to either put it in >> with an explicit pad field, or remove the BITS 32 from the type of b. >> >>> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >>> END; >>> after byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 8 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >>> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >>> END; >>> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >>>> Thanks for the explanation! How does one express the alignment >>>> you support? >>>> >>>> It does sound like <*LAZYALIGN*> can go away. >>>> >>>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>>> >>>>> Actually rather than compilain rather grumpily, maybe I can just >>>>> make the >>>>> changes required to RTTipe and do the work to reomve the pragma. >>>>> I can >>>>> work with Randy to ensure it doesn't break pickles, there is no >>>>> reason why >>>>> it should. >>>>> >>>>> On tha subject Randy, I assume pickles encode the number of BITS >>>>> FOR >>>>> for a field? If not it should. >>>>> >>>>> >>>>>> We seem to be going through these same point several times. I'm >>>>>> not sure >>>>>> what the difficulty is, I'm just repeating myself. >>>>>> >>>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>>> FOR or bit >>>>>> fields. >>>>>> >>>>>> The change I put in libralised the *M3* alignment rules so that >>>>>> BITS FOR >>>>>> fields in structures would align on byte boundries if possible >>>>>> instead of >>>>>> restricting them to word alignment generally. GCC happily >>>>>> generates code >>>>>> for this. There may be restrictions in GCC's C as to how you >>>>>> can arrange >>>>>> bit fields but I don't see what they have to do with M3. >>>>>> >>>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>>> X and its >>>>>> removal would make M3 pointless for use on the Mac, at least >>>>>> more me. >>>>>> >>>>>> This should be the default behviour. If you are using BITS FOR >>>>>> it's >>>>>> becuase you want to arrange the fields in a record in >>>>>> particular way. Why >>>>>> then arbitrarliy pad out the fields? If performance is an >>>>>> issue, the user >>>>>> should be using appropriate field bit sizes. The implementation >>>>>> rule for >>>>>> BITS FOR in M3 is implementation dependent, there are no >>>>>> language issues. >>>>>> >>>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>>> Olaf >>>>>> created and had nothing to do with me. I diagreed with it and >>>>>> never used >>>>>> it in the version of the compiler I ran. I support its removal. >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>>> >>>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>>> for it. >>>>>>>> >>>>>>>> The PRGAMA is of no use and can be removed. >>>>>>>> >>>>>>>> Does anyone have any objections to making this alignment >>>>>>>> behaviour >>>>>>>> standard? >>>>>>> >>>>>>> >>>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>>> with >>>>>>> the standard gcc-backend alignment? Perhaps I don't >>>>>>> understand what >>>>>>> it is you are doing or trying to do. Again, please remind me >>>>>>> what it >>>>>>> is that LAZYALIGN does and why it is needed. >>>>>>> >>>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>>> >>>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>>> with >>>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>>> would >>>>>>>>> argue to abandon it. >>>>>>>>> >>>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>>> >>>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>>> objects. >>>>>>>>>> I've never used LAZYALIGN. >>>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>>> add >>>>>>>>>> support for something that is rarely used. >>>>>>>>>> Regards, >>>>>>>>>> Randy >>>>>>>>>> >>>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>>> >>>>>>>>>> PM >>> >>>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>>> to >>>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>>> without >>>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>>> existing >>>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>>> >>>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>>> >>>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>>> variables of that type. >>>>>>>>>> >>>>>>>>>> Olaf Wagner wrote: >>>>>>>>>> >>>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>>> the >>>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>>> >>>>>>>>>>> Olaf >>>>>>>>>>> >>>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>>> >>>>>>>>>> LAZYALIGN. >>>>>>>>>> >>>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>>> pickles. >>>>>>>>>>> >>>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>>> >>>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>>> Using >>>>>>>>>> >>>>>>>>>> BITSIZE, >>>>>>>>>> >>>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>>> >>>>>>>>>> executing >>>>>>>>>> >>>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>>> >>>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>>> type >>>>>>>>>> >>>>>>>>>> both as >>>>>>>>>> >>>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>>> that >>>>>>>>>> >>>>>>>>>> wrote >>>>>>>>>> >>>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>>> generates is >>>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>>> >>>>>>>>>> field >>>>>>>>>> >>>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>>> builtin >>>>>>>>>> >>>>>>>>>> types). >>>>>>>>>> >>>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>>> >>>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>>> >>>>>>>>>> machine >>>>>>>>>> >>>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>>> >>>>>>>>>> description and >>>>>>>>>> >>>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>>> both >>>>>>>>>> >>>>>>>>>> as they >>>>>>>>>> >>>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>>> >>>>>>>>>> the latter, >>>>>>>>>> >>>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>>> >>>>>>>>>> stored in the >>>>>>>>>> >>>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>>> >>>>>>>>>> techniques >>>>>>>>>> >>>>>>>>>>>> like >>>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>>> >>>>>>>>>> m3core, and >>>>>>>>>> >>>>>>>>>>>> called by Pickle code. >>>>>>>>>>>> >>>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>>> compiler's >>>>>>>>>> >>>>>>>>>> layout >>>>>>>>>> >>>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>>> >>>>>>>>>> involve >>>>>>>>>> >>>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>>> different >>>>>>>>>> >>>>>>>>>> data >>>>>>>>>> >>>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>>> kind >>>>>>>>>> >>>>>>>>>> of bit >>>>>>>>>> >>>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>>> >>>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>>> >>>>>>>>>> comparing the >>>>>>>>>> >>>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>>> >>>>>>>>>> compiler. The >>>>>>>>>> >>>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>>> >>>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>>> >>>>>>>>>> small fields >>>>>>>>>> >>>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>>> pickled >>>>>>>>>> >>>>>>>>>> on a >>>>>>>>>> >>>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>>> >>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Rodney, >>>>>>>>>>>>> >>>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>>> RTPacking? I >>>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>>> >>>>>>>>>> anyway. >>>>>>>>>> >>>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>>> >>>>>>>>>> figure >>>>>>>>>> >>>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>>> >>>>>>>>>> INTEGER is >>>>>>>>>> >>>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>>> missing >>>>>>>>>>>>> something? >>>>>>>>>>>>> >>>>>>>>>>>>> -- Tony >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>>> can >>>>>>>>>> >>>>>>>>>> help with? >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>>> type >>>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>>> >>>>>>>>>> recently) >>>>>>>>>> >>>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >> >> -- >> ------------------------------------------------------------- >> 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 rodney.bates at wichita.edu Fri Feb 22 22:49:33 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 15:49:33 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> Message-ID: <47BF436D.9080608@wichita.edu> No, this is exactly what the language says and means. However, there is more, in the same section that I took for granted: "The values allowed for n are implementation-dependent. An illegal value for n is a static error. The legality of a packed type can depend on its context; for example, an implementation could prohibit packed integers from spanning word boundaries." In other words, the compiler must either locate a packed field with no preceding padding, or else emit an error, and this is what both PM3 and CM3 do. LAZYALIGN weakens the CM3's restrictions and changes the handling of your example from a a compile error to respecting the no-padding rule. Either way is consistent with the language. Darko wrote: > I think you may be reading that definition too literally. Any processor > is going to data alignment rules so 'adjacent' is subject to what can > be implemented on the processor. The problem I have is that the > existing code doesn't pack to the limits of the processor, but to some > arbitrary alignment. Thus my comment about viewing so-called lazy > alignment as a fix to an alignment bug. > > > On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > >> >> >> Darko wrote: >> >>> There wouldn't be any explicit expression. in the source, but there >>> would be a flag in Target.i3 for turning it off and on for >>> different platforms. >>> Although the details may be a bit off, the principal is this: >>> before byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> >> >> ^If the compiler's alignment rules are not lazy, then this violates >> a language rule and should not compile. From 2.2.5, Packed types: >> >> "...variables of type T that occur in records, objects, or arrays will >> occupy exactly n bits and be packed adjacent to the preceding field or >> element." >> >> To get the padding between a and b, you would have to either put it in >> with an explicit pad field, or remove the BITS 32 from the type of b. >> -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 23:01:16 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 16:01:16 -0600 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <1E474378-253C-4484-813B-A747EF28051B@darko.org> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> Message-ID: <47BF462C.6060204@wichita.edu> But pickles are working below the type safety of the language, copying bits around. True, pickles will only build an object in the reading program with the same type it had in the writing program. But the layout of fields can be different, even with the same type, for example, due to integer size, or as you say, endianness. Pickles has to be able to reconstruct the bit layout of a type both as it was on the writing machine and as it is on the reading machine. If anything LAZYALIGN is written to a pickle, then it's already broken, because pickles will have the wrong idea about where the bits of the fields are located and will garble bits. Pickles always recomputes bit layouts as the compiler would for STRICTALIGN. Which means, if you never pickle anything that is LAZYALIGN, you won't invoke this brokenness. And it sounds like nobody is doing that, so it's not broken for current uses. Darko wrote: > I don't think breaking pickles is at issue at all since the alignment > issues don't change the meaning of a type, only its layout in memory on > a particular platform, akin to endian issues. > >-- ------------------------------------------------------------- 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 rcoleburn at scires.com Sat Feb 23 01:16:36 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 22 Feb 2008 19:16:36 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> References: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> Message-ID: <47BF1F8F.1E75.00D7.1@scires.com> Mika: I believe the person you are referencing is Blair McIntyre. Last time I communicated with him he was a professor at Georgia Tech. Regards, Randy >>> Mika Nystrom 2/22/2008 4:19 PM >>> Oh I should be clear on what I mean, exactly, when I say things like that. Pickles "version 1", what was in SRC M3 and is in PM3, were never from what I understand completely implemented? For one thing, they didn't support endian-switching. A gentleman with a Scottish name that eludes me at the moment came out with "Pickles version 2", which do the endianness-switching, among other things. My "PM3" includes a lot of things from newer M3s, such as this Pickles version 2. I really am not enamored with my ancient PM3. I just need something that works reliably on Cygwin *and* FreeBSD (which it does). So adding the odd CM3 library to it is no big deal. But the TEXT issue is so deeply embedded in the compiler and runtime that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or vice versa. I am almost certain I have tested interchanging pickles between my PM3 code and some CM3 code and verified that it did work as long as there were no TEXTs involved. (It was a couple of years ago I did this; I think I spammed m3devel about it then too.) Mika "Rodney M. Bates" writes: >I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable >for another, more serious reason, namely, that the byte ordering of type >signatures in the files is different. > >I think this can be fixed by making pickle code try either byte ordering, without >invalidating any existing pickle files. There would be a very remote chance of >a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. > >Mika Nystrom wrote: >> Ugh!!! I am still using compilers that are almost ten years old >> on ALL my systems just because I need to share pickles between them >> and CM3 has a different TEXT format from my ancient PM3. Tony >> thinks there's a workaround with specials but I haven't had a chance >> to get to it yet... >> >> >> >-- >------------------------------------------------------------- >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 rcoleburn at scires.com Sat Feb 23 01:21:05 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 22 Feb 2008 19:21:05 -0500 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BF462C.6060204@wichita.edu> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> Message-ID: <47BF209D.1E75.00D7.1@scires.com> I agree with Rodney. Regards, Randy >>> "Rodney M. Bates" 2/22/2008 5:01 PM >>> But pickles are working below the type safety of the language, copying bits around. True, pickles will only build an object in the reading program with the same type it had in the writing program. But the layout of fields can be different, even with the same type, for example, due to integer size, or as you say, endianness. Pickles has to be able to reconstruct the bit layout of a type both as it was on the writing machine and as it is on the reading machine. If anything LAZYALIGN is written to a pickle, then it's already broken, because pickles will have the wrong idea about where the bits of the fields are located and will garble bits. Pickles always recomputes bit layouts as the compiler would for STRICTALIGN. Which means, if you never pickle anything that is LAZYALIGN, you won't invoke this brokenness. And it sounds like nobody is doing that, so it's not broken for current uses. Darko wrote: > I don't think breaking pickles is at issue at all since the alignment > issues don't change the meaning of a type, only its layout in memory on > a particular platform, akin to endian issues. > >-- ------------------------------------------------------------- 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 darko at darko.org Sat Feb 23 02:01:55 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 12:01:55 +1100 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BF462C.6060204@wichita.edu> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> Message-ID: <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> Then I assume RTTipe needs to be fixed, and pickles and the alignment are ok. On 23/02/2008, at 9:01 AM, Rodney M. Bates wrote: > But pickles are working below the type safety of the language, copying > bits around. True, pickles will only build an object in the reading > program with the same type it had in the writing program. But the > layout of fields can be different, even with the same type, for > example, > due to integer size, or as you say, endianness. Pickles has to be > able > to reconstruct the bit layout of a type both as it was on the writing > machine and as it is on the reading machine. > > If anything LAZYALIGN is written to a pickle, then it's already > broken, > because pickles will have the wrong idea about where the bits of the > fields are located and will garble bits. Pickles always recomputes > bit layouts as the compiler would for STRICTALIGN. > > Which means, if you never pickle anything that is LAZYALIGN, you won't > invoke this brokenness. And it sounds like nobody is doing that, so > it's not broken for current uses. > > Darko wrote: >> I don't think breaking pickles is at issue at all since the >> alignment issues don't change the meaning of a type, only its >> layout in memory on a particular platform, akin to endian issues. >> -- > ------------------------------------------------------------- > 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 darko at darko.org Sat Feb 23 02:07:16 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 12:07:16 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF436D.9080608@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> Message-ID: <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> It's been several years since I looked at the code, so my recollection is obviously faulty. But this means that the actual change is a positive one, allowing more packings to be legal, and there is no need for any pragmas. So the new alignment rules would be that for any platform that allows it, allow fields to align on byte boundaries, except traced references that must be aligned on word boundaries. This would mean that a pickle packed on a platform with the more liberal alignment might be illegal on another platform. Therefore caution should be taken, otherwise I see no problem with this. On 23/02/2008, at 8:49 AM, Rodney M. Bates wrote: > No, this is exactly what the language says and means. However, > there is > more, in the same section that I took for granted: > > "The values allowed for n are implementation-dependent. An illegal > value for n is a > static error. The legality of a packed type can depend on its > context; for example, an > implementation could prohibit packed integers from spanning word > boundaries." > > In other words, the compiler must either locate a packed field with > no preceding > padding, or else emit an error, and this is what both PM3 and CM3 > do. LAZYALIGN > weakens the CM3's restrictions and changes the handling of your > example from a > a compile error to respecting the no-padding rule. Either way is > consistent with > the language. > > Darko wrote: >> I think you may be reading that definition too literally. Any >> processor is going to data alignment rules so 'adjacent' is subject >> to what can be implemented on the processor. The problem I have is >> that the existing code doesn't pack to the limits of the >> processor, but to some arbitrary alignment. Thus my comment about >> viewing so-called lazy alignment as a fix to an alignment bug. >> On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: >>> >>> >>> Darko wrote: >>> >>>> There wouldn't be any explicit expression. in the source, but >>>> there would be a flag in Target.i3 for turning it off and on >>>> for different platforms. >>>> Although the details may be a bit off, the principal is this: >>>> before byte alignment change: >>>> RECORD >>>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >>> >>> >>> ^If the compiler's alignment rules are not lazy, then this violates >>> a language rule and should not compile. From 2.2.5, Packed types: >>> >>> "...variables of type T that occur in records, objects, or arrays >>> will >>> occupy exactly n bits and be packed adjacent to the preceding >>> field or >>> element." >>> >>> To get the padding between a and b, you would have to either put >>> it in >>> with an explicit pad field, or remove the BITS 32 from the type of >>> b. >>> > > -- > ------------------------------------------------------------- > 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 rodney.bates at wichita.edu Sat Feb 23 05:07:38 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 22:07:38 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> Message-ID: <47BF9C0A.8000804@wichita.edu> Darko wrote: > It's been several years since I looked at the code, so my recollection > is obviously faulty. But this means that the actual change is a > positive one, allowing more packings to be legal, and there is no need > for any pragmas. > > So the new alignment rules would be that for any platform that allows > it, allow fields to align on byte boundaries, except traced references > that must be aligned on word boundaries. > > This would mean that a pickle packed on a platform with the more > liberal alignment might be illegal on another platform. Therefore > caution should be taken, otherwise I see no problem with this. > > Actually, if RTTipe can detect this illegality, then it can just as easily make it legal and accommodate it, rearranging the fields to the new displacements. It already does this for other reasons anyway. The tricky design problem is how to communicate to RTTipe code, which rules were used. If a mix of different rules exists anywhere in the universe, either in different compilers or in the same compiler with different options, then it must be somehow encoded in a type description, as read by RTTipe, which rules were used. Otherwise, RTTipe not even detect this mismatch, and bits get shuffled. And do this without invalidating existing pickle files and existing compiled code (where the type descriptions are stored.) -- ------------------------------------------------------------- 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 darko at darko.org Sat Feb 23 06:33:13 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 16:33:13 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF9C0A.8000804@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> Message-ID: The alignment rules are particular to a platform, not a type (at least after we get rid of the pragma), so is there no field where we can encode some information about the platform in the pickle header or something? Where is endian stored? On 23/02/2008, at 3:07 PM, Rodney M. Bates wrote: > > > Darko wrote: >> It's been several years since I looked at the code, so my >> recollection is obviously faulty. But this means that the actual >> change is a positive one, allowing more packings to be legal, and >> there is no need for any pragmas. >> So the new alignment rules would be that for any platform that >> allows it, allow fields to align on byte boundaries, except traced >> references that must be aligned on word boundaries. >> This would mean that a pickle packed on a platform with the more >> liberal alignment might be illegal on another platform. Therefore >> caution should be taken, otherwise I see no problem with this. >> > Actually, if RTTipe can detect this illegality, then it can just > as easily make it legal and accommodate it, rearranging the fields > to the new displacements. It already does this for other reasons > anyway. > > The tricky design problem is how to communicate to RTTipe code, which > rules were used. If a mix of different rules exists anywhere in the > universe, either in different compilers or in the same compiler with > different options, then it must be somehow encoded in a type > description, > as read by RTTipe, which rules were used. Otherwise, RTTipe not > even detect > this mismatch, and bits get shuffled. And do this without > invalidating > existing pickle files and existing compiled code (where the type > descriptions are stored.) > -- > ------------------------------------------------------------- > 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 Sat Feb 23 11:14:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 10:14:49 +0000 Subject: [M3devel] response file changes? In-Reply-To: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: "response files" are files that contain command lines, to overcomecommand line length limits. (Why the limits are so small? Lame.) CM3 has built in support for them. I have seen them not be deleted reliably. While the deletion should be made more reliable, I propose they be writteninto the target directory instead of "temp". That is, nearly all writes should be into the target directory.This is what is reliably cleaned up when you run "realclean". I realize there is a tension between putting things that belong together together, and reliable deletion, vs. load balancing of I/O. "Temp" is sometimes smaller/faster. I had already worked around this by wrapping up the response file supportin Quake code that moves the file into the target directory immediatelyafter creating it. I'll be able to remove that code, and live with theunreliably deleted files only when using older tools. ? Also, the built in support uses a heuristic.For shorter command lines, it doesn't use a response file.I found that surprising and a bit disappointing.While a more immediately readable log is valuable, consistency is too. Leave it alone or make it always use a response file? The Microsoft C compiler and linker dump the output of any response filethey are given, so that gets you a readable log. I don't care all that much. Maybe I'll just look into why the deletion is unreliable, but I figure "cleanup" is always unreliable because you might control-c the build, or the compiler might crash, etc. There is a "delete on close" flag in Windows, but I think it has a problem in that you have to keep the file open and if anyone else also opens it, they might need file_share_delete, not sure. File_share_delete not being supported on Win9x, maybe not much used? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 12:04:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 12:04:46 +0100 Subject: [M3devel] response file changes? In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Two short comments: o Response files in the target directory should be OK, as long as their names are unique. o The heuristic is built-in to arglist(pfx, array), IIRC; I wouldn't change that without need. You never know what depends on it, as it has been there for a long time. Olaf Quoting Jay : > "response files" are files that contain command lines, to > overcomecommand line length limits. (Why the limits are so small? > Lame.) > CM3 has built in support for them. > I have seen them not be deleted reliably. > While the deletion should be made more reliable, I propose they be > writteninto the target directory instead of "temp". > That is, nearly all writes should be into the target directory.This > is what is reliably cleaned up when you run "realclean". > > I realize there is a tension between putting things that belong > together together, and reliable deletion, vs. load balancing of I/O. > "Temp" is sometimes smaller/faster. > I had already worked around this by wrapping up the response file > supportin Quake code that moves the file into the target directory > immediatelyafter creating it. I'll be able to remove that code, and > live with theunreliably deleted files only when using older tools. > ? > Also, the built in support uses a heuristic.For shorter command > lines, it doesn't use a response file.I found that surprising and a > bit disappointing.While a more immediately readable log is valuable, > consistency is too. > Leave it alone or make it always use a response file? > The Microsoft C compiler and linker dump the output of any response > filethey are given, so that gets you a readable log. > > I don't care all that much. > Maybe I'll just look into why the deletion is unreliable, but I > figure "cleanup" is always unreliable because you might control-c > the build, or the compiler might crash, etc. There is a "delete on > close" flag in Windows, but I think it has a problem in that you > have to keep the file open and if anyone else also opens it, they > might need file_share_delete, not sure. File_share_delete not being > supported on Win9x, maybe not much used? > > - Jay > _________________________________________________________________ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". > http://www.msnmobilefix.com/Default.aspx -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 12:59:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 11:59:46 +0000 Subject: [M3devel] paths.. In-Reply-To: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: I could be wrong about many things here: Cygwin fopen and I presume open accepts all of: c:\foo, c:/foo, /foo, \foo /foo and \foo probably have a different meaning between Cygwin and Win32. In Win32, /foo and \foo are, well, \foo, on the current drive. In Cygwin, /foo is probably /foo at the Cygwin root. I'd kind of like to be wrong here, about \foo having different meanings between them, since it a common form for me. Cygwin does not accept c:foo. In Win32 c:foo is foo in the current working directory of the C: drive. I don't think c:foo is used often, but it does have a meaning. Now, as well, cm3 has its own Path module, M3Path, but I realized tonight it also uses libm3's Pathname module a fair amount. In particular, I was having errors "shipping". This throws a big monkey wrench into where I was going. So now, after a bunch of going back and forth on various uncommited changes, I have now switched (and commited) NT386GNU to use PathnameWin32.m3. To some extent, this strikes at the core of "what is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". However, remember that Cygwin does appear to accept Win32 paths. So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that Win32 accepts /foo, is it Posix?) As well, this target still uses cygwin1.dll for its all its odd behaviors. It still uses open/read/write (again, remember that msvcrt.dll DOES expose these SAME functions..I still contend that Win32 is close enough to Posix to satisfy almost everyone..and then X Windows can be dealt with separately maybe, or Trestle/Win32 fixed). I have some more testing to do but I think this switch will fly, and various other options can go away. And I can undo the small amount I had commited. I think I'll just send my m3path.m3 diff around and then delete it. I ended up with a set based approach where host and target have a set of dir separaters, volume separaters, and separators (union of previous two). These are TINY sets, containing a maximum of three characters each, and '/' is always a member of two of them. So a set is kind of overkill. But it works out pretty ok. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 13:03:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 12:03:50 +0000 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: attached contains diffs and resulting files - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 23 Feb 2008 11:59:46 +0000Subject: [M3devel] paths.. I could be wrong about many things here: Cygwin fopen and I presume open accepts all of: c:\foo, c:/foo, /foo, \foo /foo and \foo probably have a different meaning between Cygwin and Win32.In Win32, /foo and \foo are, well, \foo, on the current drive.In Cygwin, /foo is probably /foo at the Cygwin root.I'd kind of like to be wrong here, about \foo having different meanings between them, since it a common form for me. Cygwin does not accept c:foo.In Win32 c:foo is foo in the current working directory of the C: drive.I don't think c:foo is used often, but it does have a meaning. Now, as well, cm3 has its own Path module, M3Path, but I realized tonight it also uses libm3's Pathname module a fair amount. In particular, I was having errors "shipping". This throws a big monkey wrench into where I was going.So now, after a bunch of going back and forth on various uncommited changes, I have now switched (and commited) NT386GNU to use PathnameWin32.m3. To some extent, this strikes at the core of "what is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". However, remember that Cygwin does appear to accept Win32 paths. So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that Win32 accepts /foo, is it Posix?) As well, this target still uses cygwin1.dll for its all its odd behaviors. It still uses open/read/write (again, remember that msvcrt.dll DOES expose these SAME functions..I still contend that Win32 is close enough to Posix to satisfy almost everyone..and then X Windows can be dealt with separately maybe, or Trestle/Win32 fixed). I have some more testing to do but I think this switch will fly, and various other options can go away.And I can undo the small amount I had commited.I think I'll just send my m3path.m3 diff around and then delete it. I ended up with a set based approach where host and target have a set of dir separaters, volume separaters, and separators (union of previous two). These are TINY sets, containing a maximum of three characters each, and '/' is always a member of two of them. So a set is kind of overkill. But it works out pretty ok. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: path.tar.gz Type: application/x-gzip Size: 49603 bytes Desc: not available URL: From wagner at elegosoft.com Sat Feb 23 13:39:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 13:39:09 +0100 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Jay, I'm not really happy with NT386GNU using PathnameWin32.m3. In my opininion it should just use the POSIX code, whatever problems people will have with their installation roots. (These can be avoided by using the /cygdrive/... equivalents.) Why don't we just assume that by deafult CM3 is installed in /usr/local/cm3 as for all other targets (except NT386, of course)? One thing that immediately comes to mind is that all paths output by CM3 programs will contain \ instead of / then and thus be unusable for simple copy-and-paste, as \ is the escape character in all POSIX command line tools. So this seems kind of incompatible to me. Olaf Quoting Jay : > I could be wrong about many things here: > > Cygwin fopen and I presume open accepts all of: > c:\foo, c:/foo, /foo, \foo > > /foo and \foo probably have a different meaning between Cygwin and Win32. > In Win32, /foo and \foo are, well, \foo, on the current drive. > In Cygwin, /foo is probably /foo at the Cygwin root. > I'd kind of like to be wrong here, about \foo having different > meanings between them, since it a common form for me. > > Cygwin does not accept c:foo. > In Win32 c:foo is foo in the current working directory of the C: drive. > I don't think c:foo is used often, but it does have a meaning. > > Now, as well, cm3 has its own Path module, M3Path, but I realized > tonight it also uses libm3's Pathname module a fair amount. In > particular, I was having errors "shipping". > > This throws a big monkey wrench into where I was going. > So now, after a bunch of going back and forth on various uncommited > changes, I have now switched (and commited) NT386GNU to use > PathnameWin32.m3. To some extent, this strikes at the core of "what > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > However, remember that Cygwin does appear to accept Win32 paths. > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > Win32 accepts /foo, is it Posix?) As well, this target still uses > cygwin1.dll for its all its odd behaviors. It still uses > open/read/write (again, remember that msvcrt.dll DOES expose these > SAME functions..I still contend that Win32 is close enough to Posix > to satisfy almost everyone..and then X Windows can be dealt with > separately maybe, or Trestle/Win32 fixed). > > I have some more testing to do but I think this switch will fly, and > various other options can go away. > And I can undo the small amount I had commited. > I think I'll just send my m3path.m3 diff around and then delete it. > > I ended up with a set based approach where host and target have a > set of dir separaters, volume separaters, and separators (union of > previous two). These are TINY sets, containing a maximum of three > characters each, and '/' is always a member of two of them. So a set > is kind of overkill. But it works out pretty ok. > > - Jay > _________________________________________________________________ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". > http://www.msnmobilefix.com/Default.aspx -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 14:07:09 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:07:09 +0000 Subject: [M3devel] paths.. In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: They'll be escaped.?Olaf, I'm just not sure. It could be that if I just set CM3_ROOT, CM3_INSTALL, and possibly M3_CONFIG, then the Posix code is ok. However, note as I said that Cygwin does accept these paths..The opposite problem holds too -- I like copy/pasting the error messages into file.open dialogs, and forward slashes don't work there unfortunately. I had a diff for a bit that between \ and /, would try to use whatever was already in the data. I had a problem with but it still might be viable, specifically in the Win32 paths. Maybe if I can just get it definitely usable (maybe already there) and get a distribution out, someone else can hack on this issue.. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Jay,> > I'm not really happy with NT386GNU using PathnameWin32.m3.> In my opininion it should just use the POSIX code, whatever problems> people will have with their installation roots. (These can be avoided> by using the /cygdrive/... equivalents.)> Why don't we just assume that by deafult CM3 is installed in> /usr/local/cm3 as for all other targets (except NT386, of course)?> > One thing that immediately comes to mind is that all paths output> by CM3 programs will contain \ instead of / then and thus be> unusable for simple copy-and-paste, as \ is the escape character> in all POSIX command line tools. So this seems kind of incompatible> to me.> > Olaf> > Quoting Jay :> > > I could be wrong about many things here:> >> > Cygwin fopen and I presume open accepts all of:> > c:\foo, c:/foo, /foo, \foo> >> > /foo and \foo probably have a different meaning between Cygwin and Win32.> > In Win32, /foo and \foo are, well, \foo, on the current drive.> > In Cygwin, /foo is probably /foo at the Cygwin root.> > I'd kind of like to be wrong here, about \foo having different > > meanings between them, since it a common form for me.> >> > Cygwin does not accept c:foo.> > In Win32 c:foo is foo in the current working directory of the C: drive.> > I don't think c:foo is used often, but it does have a meaning.> >> > Now, as well, cm3 has its own Path module, M3Path, but I realized > > tonight it also uses libm3's Pathname module a fair amount. In > > particular, I was having errors "shipping".> >> > This throws a big monkey wrench into where I was going.> > So now, after a bunch of going back and forth on various uncommited > > changes, I have now switched (and commited) NT386GNU to use > > PathnameWin32.m3. To some extent, this strikes at the core of "what > > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > > However, remember that Cygwin does appear to accept Win32 paths. > > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > > Win32 accepts /foo, is it Posix?) As well, this target still uses > > cygwin1.dll for its all its odd behaviors. It still uses > > open/read/write (again, remember that msvcrt.dll DOES expose these > > SAME functions..I still contend that Win32 is close enough to Posix > > to satisfy almost everyone..and then X Windows can be dealt with > > separately maybe, or Trestle/Win32 fixed).> >> > I have some more testing to do but I think this switch will fly, and > > various other options can go away.> > And I can undo the small amount I had commited.> > I think I'll just send my m3path.m3 diff around and then delete it.> >> > I ended up with a set based approach where host and target have a > > set of dir separaters, volume separaters, and separators (union of > > previous two). These are TINY sets, containing a maximum of three > > characters each, and '/' is always a member of two of them. So a set > > is kind of overkill. But it works out pretty ok.> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 14:30:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:30:28 +0000 Subject: [M3devel] bringing up NT386GNU a bit easier now In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: It is now a bit easier to bring up NT386GNU. (because of the path change mainly) Remember to remove spaces from start/ends of lines in my mail (they inhibit misformatting..email systems really stink these days..). Again, cm3cg.exe I had already, and sitting in an otherwise 5.1.8 tree so I set OMIT_GCC=yes rmdir /q/s \cm3 xcopy /fivery \cm3-min-WIN32-NT386-5.1.8 \cm3 Newer versions should of course work fine. c:\cm3\bin is in %PATH%: set PATH=c:\cygwin\bin;%PATH% Cygwin is in the %PATH%: set PATH=c:\cygwin\bin;%PATH% Remember to delete \cygwin\bin\link.exe and \cygwin\bin\cc.exe. Link.exe gets confused with the Visual C++ linker. cc.exe causes a crash in ntvdm.exe when building cm3cg (at least outside of Cygwin). gcc.exe works fine and suffices. vcvars32 has been run so cl.exe, link.exe are in %PATH%, %LIB%, and %INCLUDE% are set I'd actually like to simplify that, there is prototype code already in pylib.py. This is for bootstrapping. It shouldn't be needed once there is a binary distribution to start with. You should also be able to bootstrap from other hosts, but I haven't tried. No other variables are needed. No CM3_ROOT, CM3_INSTALL, or M3_CONFIG. First make sure you have an up to date NT386 toolset: cd C:\dev2\cm3.2\scripts\python upgrade.py once that finishes set CM3_OSTYPE=POSIX (again remember no trailing spaces..) do-cm3-all.py realclean do-cm3-front.py buildship install-cm3-compiler.py do-cm3-std.py buildship do-cm3-std will eventually hit a crash, but this is after it has gotten quite far. To verify you are really using Cygwin: findstr /i /m cygwin1.dll \cm3\bin\* \cm3\bin\cm3.exe (This is what means you are /using/ it, the others maybe aren't run.) \cm3\bin\arithmetic.dll \cm3\bin\BitVector.dll \cm3\bin\cm3cg.exe \cm3\bin\DiGraph.dll \cm3\bin\Geometry.dll \cm3\bin\m3.dll \cm3\bin\m3bundle.exe \cm3\bin\m3core.dll \cm3\bin\m3parseparams.dll \cm3\bin\m3slisp.dll \cm3\bin\mklib.exe \cm3\bin\patternmatching.dll \cm3\bin\set.dll \cm3\bin\SortedTableExtras.dll \cm3\bin\sysutils.dll \cm3\bin\table-list.dll \cm3\bin\TempFiles.dll Or watch .dll loads in a debugger: \bin\cdb \cm3\bin\cm3 ModLoad: 00400000 01212000 image00400000 ModLoad: 7c900000 7c9b0000 ntdll.dll ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll ModLoad: 61000000 61200000 C:\cygwin\bin\cygwin1.dll <<< ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL ModLoad: 77e70000 77f02000 C:\WINDOWS\system32\RPCRT4.dll - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 14:50:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:50:50 +0000 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: I guess really this is why "I" will use NT386 or NT386MINGNU, and "you" will use NT386GNU. NT386GNU should be counter whatever I like. :) Ok, I'll try that again.. (So much for those instructions I just sent out, oh well; they are still correct but after some testing..may be invalidated..) I did find that Cygwin->cm3->quake->exec("c:\cm3\bin\m3bundle") doesn't work due to these annoying path issues... - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sat, 23 Feb 2008 13:07:09 +0000Subject: Re: [M3devel] paths.. They'll be escaped.?Olaf, I'm just not sure. It could be that if I just set CM3_ROOT, CM3_INSTALL, and possibly M3_CONFIG, then the Posix code is ok. However, note as I said that Cygwin does accept these paths..The opposite problem holds too -- I like copy/pasting the error messages into file.open dialogs, and forward slashes don't work there unfortunately.I had a diff for a bit that between \ and /, would try to use whatever was already in the data.I had a problem with but it still might be viable, specifically in the Win32 paths. Maybe if I can just get it definitely usable (maybe already there) and get a distribution out, someone else can hack on this issue.. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Jay,> > I'm not really happy with NT386GNU using PathnameWin32.m3.> In my opininion it should just use the POSIX code, whatever problems> people will have with their installation roots. (These can be avoided> by using the /cygdrive/... equivalents.)> Why don't we just assume that by deafult CM3 is installed in> /usr/local/cm3 as for all other targets (except NT386, of course)?> > One thing that immediately comes to mind is that all paths output> by CM3 programs will contain \ instead of / then and thus be> unusable for simple copy-and-paste, as \ is the escape character> in all POSIX command line tools. So this seems kind of incompatible> to me.> > Olaf> > Quoting Jay :> > > I could be wrong about many things here:> >> > Cygwin fopen and I presume open accepts all of:> > c:\foo, c:/foo, /foo, \foo> >> > /foo and \foo probably have a different meaning between Cygwin and Win32.> > In Win32, /foo and \foo are, well, \foo, on the current drive.> > In Cygwin, /foo is probably /foo at the Cygwin root.> > I'd kind of like to be wrong here, about \foo having different > > meanings between them, since it a common form for me.> >> > Cygwin does not accept c:foo.> > In Win32 c:foo is foo in the current working directory of the C: drive.> > I don't think c:foo is used often, but it does have a meaning.> >> > Now, as well, cm3 has its own Path module, M3Path, but I realized > > tonight it also uses libm3's Pathname module a fair amount. In > > particular, I was having errors "shipping".> >> > This throws a big monkey wrench into where I was going.> > So now, after a bunch of going back and forth on various uncommited > > changes, I have now switched (and commited) NT386GNU to use > > PathnameWin32.m3. To some extent, this strikes at the core of "what > > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > > However, remember that Cygwin does appear to accept Win32 paths. > > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > > Win32 accepts /foo, is it Posix?) As well, this target still uses > > cygwin1.dll for its all its odd behaviors. It still uses > > open/read/write (again, remember that msvcrt.dll DOES expose these > > SAME functions..I still contend that Win32 is close enough to Posix > > to satisfy almost everyone..and then X Windows can be dealt with > > separately maybe, or Trestle/Win32 fixed).> >> > I have some more testing to do but I think this switch will fly, and > > various other options can go away.> > And I can undo the small amount I had commited.> > I think I'll just send my m3path.m3 diff around and then delete it.> >> > I ended up with a set based approach where host and target have a > > set of dir separaters, volume separaters, and separators (union of > > previous two). These are TINY sets, containing a maximum of three > > characters each, and '/' is always a member of two of them. So a set > > is kind of overkill. But it works out pretty ok.> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 23 15:35:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 23 Feb 2008 09:35:49 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF1F8F.1E75.00D7.1@scires.com> References: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> <47BF1F8F.1E75.00D7.1@scires.com> Message-ID: <8796B54C-B731-4042-9A86-D14368601CF9@cs.purdue.edu> Yes, Blair MacIntyre is still at GaTech: http://www.cc.gatech.edu/ ~blair/home.html. On Feb 22, 2008, at 7:16 PM, Randy Coleburn wrote: > Mika: > > I believe the person you are referencing is Blair McIntyre. Last > time I communicated with him he was a professor at Georgia Tech. > > Regards, > Randy > > >>> Mika Nystrom 2/22/2008 4:19 PM >>> > Oh I should be clear on what I mean, exactly, when I say things > like that. > > Pickles "version 1", what was in SRC M3 and is in PM3, were never > from what > I understand completely implemented? For one thing, they didn't > support > endian-switching. > > A gentleman with a Scottish name that eludes me at the moment came > out with "Pickles version 2", which do the endianness-switching, among > other things. > > My "PM3" includes a lot of things from newer M3s, such as this > Pickles version 2. > > I really am not enamored with my ancient PM3. I just need something > that works reliably on Cygwin *and* FreeBSD (which it does). So > adding > the odd CM3 library to it is no big deal. > > But the TEXT issue is so deeply embedded in the compiler and runtime > that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or > vice versa. > > I am almost certain I have tested interchanging pickles between my > PM3 code > and some CM3 code and verified that it did work as long as there > were no > TEXTs involved. (It was a couple of years ago I did this; I think > I spammed > m3devel about it then too.) > > Mika > > "Rodney M. Bates" writes: > >I believe from reading code, that PM3 and CM3 pickle files are non- > interchangeable > >for another, more serious reason, namely, that the byte ordering > of type > >signatures in the files is different. > > > >I think this can be fixed by making pickle code try either byte > ordering, without > >invalidating any existing pickle files. There would be a very > remote chance of > >a misrecognized type, but then this is already possible due to the > hash-code nature > of signatures anyway. This is on my to-do list for work on pickles. > > > >Mika Nystrom wrote: > >> Ugh!!! I am still using compilers that are almost ten years old > >> on ALL my systems just because I need to share pickles between them > >> and CM3 has a different TEXT format from my ancient PM3. Tony > >> thinks there's a workaround with specials but I haven't had a > chance > >> to get to it yet... > >> > >> > >> > >-- > >------------------------------------------------------------- > >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 Sat Feb 23 16:04:39 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:04:39 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: I see a lot of like: == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ --- building in NT386GNU --- ignoring ../src/m3overrides new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: synwr.lib--- shipping from NT386GNU --- This is mildly dumb. I should check as to why m3.lib changed, but an import .lib changing is rarely legitimate cause for a relink. As long as no symbols were added or removed, no relink is needed. Even then, it usually doesn't matter, but harder to tell. It's true the import .libs have "hints" as to "ordinals" but I don't think anyone cares about those. Definitely maybe the fix should be that when the import .lib is made, if the list of symbols exported is identical to the previous version, don't update the file. - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:27:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:27:59 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> I think cm3 reacts conservative if an imported library changes because programs may be built standalone. A possible optimization would be to check if the symbols are still the same (as you suggested) and avoid the re-link in case of building shared (but not if building standalone, as the symbols may be the same, but the code has changed). Olaf Quoting Jay : > I see a lot of like: > > == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build > -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] > +++ > --- building in NT386GNU --- > > ignoring ../src/m3overrides > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib > *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo > SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared > -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: > synwr.lib--- shipping from NT386GNU --- > > This is mildly dumb. > I should check as to why m3.lib changed, but an import .lib changing > is rarely legitimate cause for a relink. > As long as no symbols were added or removed, no relink is needed. > Even then, it usually doesn't matter, but harder to tell. > > It's true the import .libs have "hints" as to "ordinals" but I don't > think anyone cares about those. > > Definitely maybe the fix should be that when the import .lib is > made, if the list of symbols exported is identical to the previous > version, don't update the file. > > - Jay > _________________________________________________________________ > Connect and share in new ways with Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 16:32:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:32:16 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> Message-ID: Granted, just given a file path and a timestamp -- don't know if it is an import .lib or not. Either takes more smarts on the consumer, or I think more likely, more smarts on the producer. At least on Windows, the .objs within an import .lib are easily discernable as the special import type and not containing static code. You can actually have hybrid .libs. For example msvcrt.lib contains mostly imports but also static startup code (thus no need for crt0.o or such). Anyway, I think the smarts belong in the producer as that is what would lead to less i/o. I'm starting to need a bug database. :) e.g. cleanup this redundancy: C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.m3(226): tm := localtime(ADR(secs))^ C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; (make ANSI time.h available on Win32 also, if it helps) - Jay > Date: Sat, 23 Feb 2008 16:27:59 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] unnecessary relinks when import libs change> > I think cm3 reacts conservative if an imported library changes> because programs may be built standalone. A possible optimization> would be to check if the symbols are still the same (as you suggested)> and avoid the re-link in case of building shared (but not if building> standalone, as the symbols may be the same, but the code has changed).> > Olaf> > Quoting Jay :> > > I see a lot of like:> >> > == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build > > -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > > 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] > > +++> > --- building in NT386GNU ---> >> > ignoring ../src/m3overrides> > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib > > *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo > > SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared > > -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: > > synwr.lib--- shipping from NT386GNU ---> >> > This is mildly dumb.> > I should check as to why m3.lib changed, but an import .lib changing > > is rarely legitimate cause for a relink.> > As long as no symbols were added or removed, no relink is needed.> > Even then, it usually doesn't matter, but harder to tell.> >> > It's true the import .libs have "hints" as to "ordinals" but I don't > > think anyone cares about those.> >> > Definitely maybe the fix should be that when the import .lib is > > made, if the list of symbols exported is identical to the previous > > version, don't update the file.> >> > - Jay> > _________________________________________________________________> > Connect and share in new ways with Windows Live.> > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 16:38:18 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:38:18 +0000 Subject: [M3devel] response file changes? In-Reply-To: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: Nobody should depend on this strange heuristic-based behavior.. I know that doesn't make it so, but it does possibly legitimize changing it. > as long as their names are unique. Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt. I wrap around from 9 to 0 because Quake can't do math. In practise there's only ever one or two response files per directory, one to make in import .lib and one make a .dll, or just one to link an .exe. C compilation doesn't use response files, but it could if the parameters got long and esp. if there were lots of C files in one directory and batch compile them instead of one at a time.. That's a nice optimization in C-based systems, not a big deal in Modula-3 with so few .c files. Maybe soon I'll rip out my code, and then fix the reliable deletion, and THEN move the directory... - Jay > Date: Sat, 23 Feb 2008 12:04:46 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] response file changes?> > Two short comments:> > o Response files in the target directory should be OK, as long as> their names are unique.> > o The heuristic is built-in to arglist(pfx, array), IIRC; I wouldn't> change that without need. You never know what depends on it, as it> has been there for a long time.> > Olaf> > Quoting Jay :> > > "response files" are files that contain command lines, to > > overcomecommand line length limits. (Why the limits are so small? > > Lame.)> > CM3 has built in support for them.> > I have seen them not be deleted reliably.> > While the deletion should be made more reliable, I propose they be > > writteninto the target directory instead of "temp".> > That is, nearly all writes should be into the target directory.This > > is what is reliably cleaned up when you run "realclean".> >> > I realize there is a tension between putting things that belong > > together together, and reliable deletion, vs. load balancing of I/O. > > "Temp" is sometimes smaller/faster.> > I had already worked around this by wrapping up the response file > > supportin Quake code that moves the file into the target directory > > immediatelyafter creating it. I'll be able to remove that code, and > > live with theunreliably deleted files only when using older tools.> > ?> > Also, the built in support uses a heuristic.For shorter command > > lines, it doesn't use a response file.I found that surprising and a > > bit disappointing.While a more immediately readable log is valuable, > > consistency is too.> > Leave it alone or make it always use a response file?> > The Microsoft C compiler and linker dump the output of any response > > filethey are given, so that gets you a readable log.> >> > I don't care all that much.> > Maybe I'll just look into why the deletion is unreliable, but I > > figure "cleanup" is always unreliable because you might control-c > > the build, or the compiler might crash, etc. There is a "delete on > > close" flag in Windows, but I think it has a problem in that you > > have to keep the file open and if anyone else also opens it, they > > might need file_share_delete, not sure. File_share_delete not being > > supported on Win9x, maybe not much used?> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:40:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:40:52 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> Message-ID: <20080223164052.lswpp1pc4ksgwwkw@mail.elegosoft.com> Quoting Jay : > Granted, just given a file path and a timestamp -- don't know if it > is an import .lib or not. > Either takes more smarts on the consumer, or I think more likely, > more smarts on the producer. > At least on Windows, the .objs within an import .lib are easily > discernable as the special import type and not containing static > code. You can actually have hybrid .libs. For example msvcrt.lib > contains mostly imports but also static startup code (thus no need > for crt0.o or such). Anyway, I think the smarts belong in the > producer as that is what would lead to less i/o. > > I'm starting to need a bug database. :) We've got one, but it's not externally accessible, and hasn't been used much recently. I've already discussed this topic with others at elego, and we'll setup something during the next weeks (hopefully). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 16:42:53 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:42:53 +0000 Subject: [M3devel] response file changes? In-Reply-To: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: truncated again... "rip out my code" btw is Quake code in the NT386 config files (and also similar in m3cc and m3gdb on Windows platforms) - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] response file changes?Date: Sat, 23 Feb 2008 15:38:18 +0000 Nobody should depend on this strange heuristic-based behavior..I know that doesn't make it so, but it does possibly legitimize changing it. > as long as their names are unique. Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt.I wrap around from 9 to 0 because Quake can't do math.In practise there's only ever one or two response files per directory, one to make in import .lib and one make a .dll, or just one to link an .exe.C compilation doesn't use response files, but it could if the parameters got long and esp. if there were lots of C files in one directory and batch compile them instead of one at a time.. That's a nice optimization in C-based systems, not a big deal in Modula-3 with so few .c files. Maybe soon I'll rip out my code, and then fix the reliable deletion, and THEN move the directory... - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 16:47:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:47:50 +0000 Subject: [M3devel] paths.. In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: oky doky it's back to Posix, and pylib.py sniffs cm3.exe to see which it wants...seems to be working pretty ok.. and I still don't need to set those pesky environment variables phew. :) If I can just push out a make-dist output maybe someone will load balance? I still think some things could be improved a bit in terms of knowing or probing host and target behavior. You know, OS_TYPE is target, not host. I cheat and use the OS environment variable, which is Windows_NT on Windows (ignoring 9x). Pushing more stuff into Modula-3 -- "expanding the portable host" -- a la sysutils, definitely helps. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> > I'm not really happy with NT386GNU using PathnameWin32.m3. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:52:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:52:06 +0100 Subject: [M3devel] response file changes? In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: <20080223165206.mna5tqyi2o0kokg0@mail.elegosoft.com> Quoting Jay : > Nobody should depend on this strange heuristic-based behavior.. > I know that doesn't make it so, but it does possibly legitimize changing it. OK, probably you're right there. > > as long as their names are unique. > > Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt. > I wrap around from 9 to 0 because Quake can't do math. > In practise there's only ever one or two response files per > directory, one to make in import .lib and one make a .dll, or just > one to link an .exe. We could just add a function to create a unique tmpfile name in a given directory to quake. There's the tempfiles package in m3-libs. Olaf > C compilation doesn't use response files, but it could if the > parameters got long and esp. if there were lots of C files in one > directory and batch compile them instead of one at a time.. That's a > nice optimization in C-based systems, not a big deal in Modula-3 > with so few .c files. > > Maybe soon I'll rip out my code, and then fix the reliable deletion, > and THEN move the directory... > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Feb 23 17:24:29 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 23 Feb 2008 11:24:29 -0500 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Why @M3novm? That should no longer be needed. On Feb 23, 2008, at 10:04 AM, Jay wrote: > I see a lot of like: > > == package C:\\dev2\\cm3.2\m3-obliq\synloc == > +++ ['cm3.exe -build -keep -DROOT=/C/dev2/cm3.2 - > DCM3_VERSION_TEXT=d5.6.0 -DCM3 > _VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > 'cm3.exe -ship -k > eep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 - > DCM3_VERSION_NUMBER=050600 - > DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ > > --- building in NT386GNU --- > > ignoring ../src/m3overrides > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving > synwr.lib *** This line **** > mklib -out:synwr.lib SynWr.io SynWr.mo SynLocation.io > SynLocation.mo 2>&1 > sy > nwr.lst > gcc -shared -Wl, at _m3responsefile1.txt 2>&1 > synwr.lst > Creating library file: synwr.lib > --- shipping from NT386GNU --- > > This is mildly dumb. > I should check as to why m3.lib changed, but an import .lib > changing is rarely legitimate cause for a relink. > As long as no symbols were added or removed, no relink is needed. > Even then, it usually doesn't matter, but harder to tell. > > It's true the import .libs have "hints" as to "ordinals" but I > don't think anyone cares about those. > > Definitely maybe the fix should be that when the import .lib is > made, if the list of symbols exported is identical to the previous > version, don't update the file. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Sat Feb 23 17:42:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 16:42:27 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: For bootstrapping from older tools. I have one set of configuration files (the checked in ones) that don't require any editing and do whatever runtime probing is needed (such as for the gc wrap flags on PPC_LINUX). I have a consistent crash building with older tools that I wasn't able to debug or otherwise workaround. On Windows I occasionally start over from 5.1.8. 5.1.3 would work but sysutils can't be compiled against its runtime. I was going to see about booting from 4.1 or 3.6 but I figure no go for the same reason. I've asked but no answer as to what people think about buildability with older tools. Probably it's not a valuable battle, otherwise progress is blocked. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] unnecessary relinks when import libs change> Date: Sat, 23 Feb 2008 11:24:29 -0500> To: jayk123 at hotmail.com> > Why @M3novm? That should no longer be needed. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sat Feb 23 18:31:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 23 Feb 2008 11:31:36 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> Message-ID: <47C05878.1050101@wichita.edu> I guess I misunderstood. I had the idea from the quoted text below that MAC OS X needed a mixture of lazy and strict alignment. If every platform uses the same alignment rules for all types of all programs on the platform, then the alignment rule property can just be made an additional field of the RTPacking.T. This is much easier to do without compatibility problems, because this value is encoded in bits in a 32-bit word in pickle headers, with unused bits that are now ignored. The alignment strategy could just be in another bit. From a post on 2-11: --------------------------------------------------------------------------------------------------------- That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for historical reasons. All other structures should use normal alignment to be compatible with C and Unix interfaces. The alignment change was implemented to be supported only in packed structures as a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly restrictive alignment rules in packed structures. On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > It sounds like all that Mac OS X needs is for _all_ types in an entire > program to use the liberal packing rules. Have I understood correctly? > I would have no grief over that. --------------------------------------------------------------------------------------------------------- Darko wrote: > The alignment rules are particular to a platform, not a type (at least > after we get rid of the pragma), so is there no field where we can > encode some information about the platform in the pickle header or > something? Where is endian stored? > > -- ------------------------------------------------------------- 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 Sat Feb 23 18:36:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 17:36:12 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: scripts\pylib.py: ## workaround crash when booting from 5.1.3 that is# difficult to debug -- crashes earlier in debugger# without this switch, no repro with this switch## This has no effect with current tools/libraries.#DEFS += " @M3novm" From: jayk123 at hotmail.com.. > From: hosking at cs.purdue.edu> > Why @M3novm? That should no longer be needed. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 18:40:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 18:40:25 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: <20080223184025.arvp8z5lc8ww4wgg@mail.elegosoft.com> Quoting Jay : > On Windows I occasionally start over from 5.1.8. > 5.1.3 would work but sysutils can't be compiled against its runtime. > I was going to see about booting from 4.1 or 3.6 but I figure no go > for the same reason. That's probably because modules have been added to m3core and libm3. > I've asked but no answer as to what people think about buildability > with older tools. > Probably it's not a valuable battle, otherwise progress is blocked. I don't think it's worth the efforts to try to remain boot-compatible with all older versions of M3. We can still use cross-compilation if there's dire need. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 19:11:29 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 18:11:29 +0000 Subject: [M3devel] NT386GNU distribution available (Cygwin this time) In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: birch: /var/www/modula3.elegosoft.com/cm3/uploaded-archives Now has cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 It doesn't appear on http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html This is a "Cygwin" based release.(From now on, the older MinGWin-based target will probably be called NT386MINGNU,though there are archives out there named "NT386GNU" that are MinGWin-based). It extracts like: tar xfj cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 cm3-min-POSIX-NT386GNU-d5.6.0/bin/cm3.cfg cm3-min-POSIX-NT386GNU-d5.6.0/bin/cm3.exe ... and then you rename or copy to \cm3 or /usr/local/cm3 or whatever. If you are using scripts\python\*, then set CM3_OSTYPE=POSIX and everything else should be figured out. TBD: If cl.exe/link.exe aren't on the path, then setting CM3_OSTYPE ought not be necessary. Sniffing uname and gcc -v should suffice. But that isn't the case yet. This distribution also includes the config files for NT386 and NT386MINGNU and should be able to target them. You can edit the one line cm3.cfg. I didn't test that aspect. (Really, if you build the cross gcc/ld tools, any cm3 can target any target.) A reasonable way to go is thus: tar xvj cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 rmdir /q/s \cm3 xcopy /fivery cm3-min-POSIX-NT386GNU-d5.6.0 \cm3 set PATH=c:\cm3\bin;c:\cygwin\bin;%PATH% cd \dev2\cm3.2\scripts\python upgrade do-cm3-all realclean do-cm3-std buildship It will error eventually, but after building a lot. Anyone game to try it and report back? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 19:26:55 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 18:26:55 +0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47C05878.1050101@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> Message-ID: kind of obnoxious of me here sorry: I am not volunteering to do any work here. :) I propose that declaration that interface with C be declared PACKED (if that even exists) or BITS n FOR (I know that exists; it was pointed out to me and I have been using it). I would like to be able to say BYTES n FOR, but ok, I say BITS n * 8 FOR. I propose there be a command line switch, or interface/module-level pragma that issues warnings or errors for any apparent need to insert any padding. I propose that any padding for alignment that is needed to interface with existing C code be explicitly inserted. I propose that when you say BITS n FOR, you be able to get a warning/error if the size isn't exactly right. I know it is already an error today if the size is too small, but I assume the compiler will grow the type to fit if it is "too big" and I'd rather not have that. On the other hand, while I have been using BITS n FOR, I make up an arbitrary type. That is, I say: Foo = BITS exact FOR RECORD blah blah pad : BITS exact FOR arbitrary small type such as [0..0] END; While I don't want the compiler to expand Foo up to exact, I don't care about the [0..0] thing. I guess in the interest of being less lazy and coming up with a simpler feature set, I am willing to be more precise in the padding. Or maybe a new type can be invented BITS exact for Padding. And maybe you can tack on ":= 0" to it, no matter the size. (Notice how in the socket code, the type of the padding can't be changed willy nilly because there is code to zero initialize it; seems a little bit lame to me.) I would probably volunteer to do some of the header repair here. Alignment issues bother me and I think we might be in a position to solve them once and for all for Modula-3, in a reasonable simple, clear, reliable, multi-target way. Part of this proposal would need to distinguish at least three scenarios: exact layout for interfacing with existing C stable layout for interface with self -- declare some new type in Modula-3 that I can pickle on multiple platforms but which Modula-3 can determine the layout of; padding can be inserted here but it must be the same across various time/space/configuration don't care layout for data that will only ever be in memory and shared amongst code built by the same basic compiler with the same declarations; padding can be inserted here and vary from build to build or such another case: exact layout for interfacing with existing Modula-3/pickles. Or maybe simply pickles need persisted metadata about the various fields, offsets, sizes? I have never used pickles or looked at the code... - Jay > Date: Sat, 23 Feb 2008 11:31:36 -0600> From: rodney.bates at wichita.edu> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] <*LAZYALIGN*>> > I guess I misunderstood. I had the idea from the quoted text below that MAC OS X needed a mixture> of lazy and strict alignment. If every platform uses the same alignment rules for all types of all> programs on the platform, then the alignment rule property can just be made an additional field of> the RTPacking.T.> > This is much easier to do without compatibility problems, because this value is encoded in bits> in a 32-bit word in pickle headers, with unused bits that are now ignored. The alignment strategy> could just be in another bit.> > > From a post on 2-11:> ---------------------------------------------------------------------------------------------------------> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for > historical reasons. All other structures should use normal alignment to be compatible with C and > Unix interfaces. The alignment change was implemented to be supported only in packed structures as > a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly > restrictive alignment rules in packed structures.> > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:> > > It sounds like all that Mac OS X needs is for _all_ types in an entire> > program to use the liberal packing rules. Have I understood correctly?> > I would have no grief over that.> ---------------------------------------------------------------------------------------------------------> > Darko wrote:> > The alignment rules are particular to a platform, not a type (at least > > after we get rid of the pragma), so is there no field where we can > > encode some information about the platform in the pickle header or > > something? Where is endian stored?> > > > > -- > -------------------------------------------------------------> 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 _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 20:29:11 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 20:29:11 +0100 Subject: [M3devel] NT386GNU distribution available (Cygwin this time) In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: <20080223202911.ca9eq2e74kwcgwck@mail.elegosoft.com> Quoting Jay : > birch: /var/www/modula3.elegosoft.com/cm3/uploaded-archives > Now has cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 > It doesn't appear on > http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html This is because it is no `daily snapshot'. Daily snapshots are built by the daily regression runs. Uploaded files appear on http://www.opencm3.net/ --> Installation --> Uploaded Archives: http://www.opencm3.net/uploaded-archives/index.html :-) You could also add the description from your email as one of cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2.{README,txt,html} and an appropriate link will be shown on the page. The index is updated every 30 minutes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 21:03:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 21:03:23 +0100 Subject: [M3devel] CM3 Tinderbox Display Message-ID: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> I've made some changes to the tinderbox display: 1. The last 48 hours are displayed by default now. 2. I switched the display mode from build-event time to event time. In build-event time (which is more compact), current build records were often not displayed for unknown reasons. Someone with more perl knowlege must look into this (Ronny?) With event time granularity, we get an entry for every CVS checkin, too. 3. I changed the VC switch in DBImpl from 'TinderDB::VC_Bonsai' to 'TinderDB::VC_CVS'. This seems to give us some entries in the Guilty column. The previous build time in the pop-ups is still broken, so that the Bonsai queries for `check-ins since last build' don't work. I also disabled some suspicious db deletes in the perl code, which may have been responsible for the loss of data we've seen (I386_DARWIN, for example). BTW, is there a Perl guru on this list who could fix things faster than me? (Our administrator cannot spend too much time for this stuff, and Kaspar seems still to be bound by his studies.) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 21:28:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 20:28:32 +0000 Subject: [M3devel] CM3 Tinderbox Display In-Reply-To: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: I'm so-so with Perl..but way out of context, and not done any database stuff in any domain...have started trying to run the tinderbox and regression tests today..some luck running the tests, not much with tinderbox yet..I got it to do the cvs checkout, and I extracted my archive where it wanted it..got as far as: $ ( . defs.sh ; test_build_core_rel )hostname: invalid option -- sTry `hostname --help' for more information.TESTHOSTNAME=WS=/home/Jay/work/cm3-ws/-2008-02-23-20-23-57LASTREL=5.4.0INSTROOT_REL=/home/Jay/work/cm3-inst//rel-5.4.0INSTROOT_POK=/home/Jay/work/cm3-inst//prev-okINSTROOT_LOK=/home/Jay/work/cm3-inst//last-okINSTROOT_CUR=/home/Jay/work/cm3-inst//currentCM3_OSTYPE=WIN32CM3_TARGET=NT386BINDISTMIN=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2CM3CVSSERVER=jkrell at m3.elegosoft.comCM3CVSROOT=:ext:jkrell at m3.elegosoft.com:/usr/cvsBINDISTMIN_NAME=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2BINDISTMIN=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2testing ssh jkrell at m3.elegosoft.com..ssh jkrell at m3.elegosoft.com ok === 2008-02-23 20:24:01 build cm3 core in /home/Jay/work/cm3-ws/-2008-02-23-20-23-57 with last release /home/Jay/work/cm3-inst//rel-5.4.0Critical Mass Modula-3 version d5.6.0 last updated: 2008-01-31 compiled: 2008-02-23 17:41:32 configuration: /home/Jay/work/cm3-inst//current/bin/cm3.cfg bash: cd: /home/Jay/work/cm3-ws/-2008-02-23-20-23-57/cm3: No such file or directorygotta run for a while. - Jay > Date: Sat, 23 Feb 2008 21:03:23 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> CC: m3-support at elegosoft.com; tobermueller at elegosoft.com> Subject: [M3devel] CM3 Tinderbox Display> > I've made some changes to the tinderbox display:> > 1. The last 48 hours are displayed by default now.> > 2. I switched the display mode from build-event time to> event time. In build-event time (which is more compact),> current build records were often not displayed for unknown> reasons. Someone with more perl knowlege must look into this> (Ronny?) With event time granularity, we get an entry for> every CVS checkin, too.> > 3. I changed the VC switch in DBImpl from 'TinderDB::VC_Bonsai' to> 'TinderDB::VC_CVS'. This seems to give us some entries in the> Guilty column.> > The previous build time in the pop-ups is still broken, so that> the Bonsai queries for `check-ins since last build' don't work.> > I also disabled some suspicious db deletes in the perl code,> which may have been responsible for the loss of data we've seen> (I386_DARWIN, for example).> > BTW, is there a Perl guru on this list who could fix things faster> than me? (Our administrator cannot spend too much time for this stuff,> and Kaspar seems still to be bound by his studies.)> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 24 01:01:05 2008 From: darko at darko.org (Darko) Date: Sun, 24 Feb 2008 11:01:05 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47C05878.1050101@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> Message-ID: <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> What I meant to say below is that unpacked structures are aligned according to the normal rules under Darwin. The problem is that the packed alignment rules without the change are too restrictive. On 24/02/2008, at 4:31 AM, Rodney M. Bates wrote: > I guess I misunderstood. I had the idea from the quoted text below > that MAC OS X needed a mixture > of lazy and strict alignment. If every platform uses the same > alignment rules for all types of all > programs on the platform, then the alignment rule property can just > be made an additional field of > the RTPacking.T. > > This is much easier to do without compatibility problems, because > this value is encoded in bits > in a 32-bit word in pickle headers, with unused bits that are now > ignored. The alignment strategy > could just be in another bit. > > > From a post on 2-11: > --------------------------------------------------------------------------------------------------------- > That's not quite right. Certain Mac API structures need to be > aligned to Motorola 68K alignment for historical reasons. All other > structures should use normal alignment to be compatible with C and > Unix interfaces. The alignment change was implemented to be > supported only in packed structures as a natural and intuitive way > to "force" alignment. You could view it as a bug fix to overly > restrictive alignment rules in packed structures. > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > > > It sounds like all that Mac OS X needs is for _all_ types in an > entire > > program to use the liberal packing rules. Have I understood > correctly? > > I would have no grief over that. > --------------------------------------------------------------------------------------------------------- > > Darko wrote: >> The alignment rules are particular to a platform, not a type (at >> least after we get rid of the pragma), so is there no field where >> we can encode some information about the platform in the pickle >> header or something? Where is endian stored? > -- > ------------------------------------------------------------- > 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 Feb 24 01:22:29 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 00:22:29 +0000 Subject: [M3devel] exposing both path name types? In-Reply-To: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: What is the idiom for this: Currently: There is Pathname.i3. PathnamePosix EXPORTS Pathname PathnameWin32 EXPORTS Pathname You can only have one in a link. It would seem possibly useful to have: Pathname.i3 unchanged PathnamePosix.i3 identical to Pathname.i3 (some what to avoid the duplication?) PathnameWin32.i3 identical to Pathname.i3 (ditto) On Posix targets: PathnameWin32.m3 exports just PathnameWin32 PathnamePosix exports both PathnamePosix and Pathname On Windows targets: PathnamePosix exports just PathnamePosix PathnameWin32 exports both PathnameWin32 and Pathname That is Pathname.Foo resolves statically at compile time to the target-specific library. PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. These modules each import nothing, except Text. They do all their string manipulation themselves. Olaf's recent Quake extensions document but don't implement pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> text As long as pn is a fullpath, these are easy, I just wrote up prototypes, haven't compiled them. I think these functions might suggest doing what I'm asking about as well, maybe. Or maybe you'd just convert and then never pick back apart. I have sleazed by for now by using subst_text / to \ and setting up NTFS junctions. In this way, I can cross build NT386 <=> NT386GNU either host, either target. Had I not done anything, the linker interprets /cygdrive/c/foo/bar.lib as a command switch and says it doesn't understand it. Not a big deal, but I think there might be some easy progress here. This is not just about Pathname. It is also about File. Even though NT386GNU File is FilePosix, it would be useful to allow the serial package to use FileWin32 instead. But FilePosix and FileWin32 both reveal the same types. It'd be nice if they could expose FilePosix.T and FileWin32.T and then only one of them reveal File.T = FilePosix.T or File.T = FileWin32.T, something like that. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 24 01:34:13 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 00:34:13 +0000 Subject: [M3devel] exposing both path name types? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: Oh I think I see some of how to do this. Olaf's path stuff is actually implemented, maybe just not exposed, and perhaps incomplete, but it demonstrates a "trick" of Modula-3. You can do this: INTERFACE I; PROCEDURE F1(); PROCEDURE F2(); END I; MODULE A EXPORTS I; PRODEDURE F1() = ... END F1; MODULE B EXPORTS I; PRODEDURE F2() = ... END F2; The implementation of interface can be distributed among multiple modules. To export an interface just means to implement some or all of it. Usually but not necessarily all. (I wonder what if you implement none of it?) That helps much. It doesn't provide a complete idiom I think for what I ask, but it is a start. I suspect generics help here. But I'm still not sure what the entire answer is. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sun, 24 Feb 2008 00:22:29 +0000Subject: [M3devel] exposing both path name types? What is the idiom for this: Currently:There is Pathname.i3.PathnamePosix EXPORTS PathnamePathnameWin32 EXPORTS PathnameYou can only have one in a link. It would seem possibly useful to have:Pathname.i3 unchangedPathnamePosix.i3 identical to Pathname.i3 (some what to avoid the duplication?)PathnameWin32.i3 identical to Pathname.i3 (ditto) On Posix targets: PathnameWin32.m3 exports just PathnameWin32 PathnamePosix exports both PathnamePosix and Pathname On Windows targets: PathnamePosix exports just PathnamePosix PathnameWin32 exports both PathnameWin32 and Pathname That is Pathname.Foo resolves statically at compile time to the target-specific library.PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. These modules each import nothing, except Text. They do all their string manipulation themselves. Olaf's recent Quake extensions document but don't implement pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> textAs long as pn is a fullpath, these are easy, I just wrote up prototypes, haven't compiled them. I think these functions might suggest doing what I'm asking about as well, maybe.Or maybe you'd just convert and then never pick back apart. I have sleazed by for now by using subst_text / to \ and setting up NTFS junctions.In this way, I can cross build NT386 <=> NT386GNU either host, either target.Had I not done anything, the linker interprets /cygdrive/c/foo/bar.lib as a command switch and says it doesn't understand it.Not a big deal, but I think there might be some easy progress here. This is not just about Pathname. It is also about File.Even though NT386GNU File is FilePosix, it would be useful to allow the serial package to use FileWin32 instead.But FilePosix and FileWin32 both reveal the same types.It'd be nice if they could expose FilePosix.T and FileWin32.T and then only one of them reveal File.T = FilePosix.T or File.T = FileWin32.T, something like that. - Jay Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 24 01:59:03 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 24 Feb 2008 01:59:03 +0100 Subject: [M3devel] Do I remember well... Message-ID: <1203814743.7865.25.camel@hias.m3w.org> Once, there was a talk about (original?) CM3 making checked runtime errors behave like exceptions? -- Dragi?a Duri? From wagner at elegosoft.com Sun Feb 24 02:19:34 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 02:19:34 +0100 Subject: [M3devel] Do I remember well... In-Reply-To: <1203814743.7865.25.camel@hias.m3w.org> References: <1203814743.7865.25.camel@hias.m3w.org> Message-ID: <20080224021934.ll0vw5k2swoooccs@mail.elegosoft.com> Quoting Dragi?a Duri? : > Once, there was a talk about (original?) CM3 making checked runtime > errors behave like exceptions? Yes. See http://www.opencm3.net/about-cm3.html: o <*IMPLICIT*> exceptions (changes language semantics) o checked runtime errors are mapped to the implicit exception RuntimeError.E I don't think anything has changed in this area. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 24 12:03:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 11:03:34 +0000 Subject: [M3devel] another nt/posix target? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: This is really getting a head of things, but I think maybe there should be a target for "Services for Unix". Probably called X86_INTERIX or something? Or X86_INTERIX_GCC and X86_INTERIX_MSVC? Or X86_SFU_GNU, X86_SFU_MS? Or simply X86_NTX? I think the different tools might not matter -- might be just "cc" vs. "gcc" and the same runtime, same setjmp buffer. It looks like you have a choice of compilers. It looks like a pretty good system from a Posix point of view. I have to try it out more. And maybe stay on other areas for now. Pthreads looks definitely viable here, so start with the Cygwin "minimized" "headers" (.i3) files, correct them, add back pthreads (and dependent signal stuf..) I know it's too late, but I guess naming scheme should have included "OS_TYPE". X86_WIN32_MSVC X86_WIN32_BLAND (Borland) X86_WIN32_DMARS (Digital Mars) X86_WIN32_WAT (Open Watcom) X86_WIN32_GCC (MinGWin) or maybe clearer X86_WIN32_MINGWIN X86_POSIX_GCC (Cygwin) or maybe clearer X86_POSIX_CYGWIN X86_POSIX_SFU or X86_POSIX_INTERIX or X86_POSIX_INTERIX_GCC or X86_POSIX_INTERIX_MSVC etc. Then, to the extent that these are all the same, it seems like I did a good thing separating "target" from "configuration"? Or again, compiler is a configuration thing, runtime due to jmpbuf size is something the compiler needs to know about, and processor actually the compiler hardly cares about -- it has to know 32bit vs. 64bit, and then just to call cm3cg usually.. :) Anyway, let's retable the general issue and just, PERHAPS, discuss Interix/SFU. A target/config name is probably all, X86_INTERIX or X86_SFU, or X86_MSWINX or X86_WINPOSIX or X86_POSIX_MS or X86_POSIX_NT X86_NTPOSIX something.. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 24 16:42:02 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 15:42:02 +0000 Subject: [M3devel] duplicate link info for stuff that has been deleted? In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: do-cm3-std buildship == package C:\dev2\cm3.2\m3-www\http == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5. 6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSI ON_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ --- building in NT386GNU --- ignoring ../src/m3overrides Fatal Error: duplicate link info: FastLex.i3 I know I know, not a big deal, easy workaround: => do-pkg http realclean But is this something the builder is supposed to handle? I'm too lazy to read the code right now... ps: here's a hueristic: if two libraries have identical code, it might be a good candidate for libm3? :) (I'm all for kitchen sink libraries, that way I can just depend on one and not worry about it. I'm a heretic though, I know.) - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 24 16:53:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:53:16 +0100 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: <20080224165316.xibqnumt6sg0s8kk@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Jay : > >> Oh darn, inevitably that is not my final answer.. >> more like attached.. > > Jay, > > the files seem to work OK on my FreeBSD system. But the tinderbox > tests on birch and new have failed, in spite of my CVS revert; > so please don't commit anything until I have found out what is wrong. > It may take some time, because I'm expecting guests soon and won't > be able to do much until tomorrow evening. OK, I think I've found it, two different reasons for the failures. On Linux we need to use libiodbc instead of libodbc as on FreeBSD, and on new.elego.de the changes just hadn't been cvsupped. On Darwin the tests succeeded again, though, so my change had an effect. Jay, you can commit your latest cm3 versions now, and I'll try to correct the odbc stuff. We'll know if it works tomorrow morning then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 24 16:58:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 15:58:20 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: Ok, I see: http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-FreeBSD4.html#tr_m3-db-odbcIt really must be: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Path.m3.diff?r1=1.14;r2=1.15 The error is unable to open "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../odbc/FreeBSD4/.M3EXPORTS" but it should be trying to open: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../../../odbc/FreeBSD4/.M3EXPORTS" or, fixed up: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/FreeBSD4/.M3EXPORTS" My change is making it remove two instances of .. at once or something like that. I still am not reading it fully, but this must be it. Overrides are often/usually "built down" from ROOT, but in this case they are "built up". Anyway I'm off to debug: == package C:\dev2\cm3.2\m3-obliq\obliqrt == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++--- building in NT386GNU --- ignoring ../src/m3overrides /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB/cygdrive/C/cm3/bin/shobjcodegen: Processing ObValue.ReplObjStd"/cygdrive/C/cm3/pkg/sharedobj/src/sharedobj.tmpl", line 49: quake runtime error: exit 35584: /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB and I have guests coming soon too. :) - Jay > Date: Sun, 24 Feb 2008 16:32:05 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: Revert cm3 to version 6 days ago> > Quoting Jay :> > > Oh darn, inevitably that is not my final answer..> > more like attached..> > Jay,> > the files seem to work OK on my FreeBSD system. But the tinderbox> tests on birch and new have failed, in spite of my CVS revert;> so please don't commit anything until I have found out what is wrong.> It may take some time, because I'm expecting guests soon and won't> be able to do much until tomorrow evening.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000> >> >> > Olaf can you try the attached? Thanks, - Jay> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Feb 24 22:54:34 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 Feb 2008 13:54:34 -0800 Subject: [M3devel] paths.. In-Reply-To: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Olaf, you're right: People who use Cygwin are used to dealing with all kinds of oddities. I am here reproducing "README.CYGWIN" from the top level of my M3 project (note the stuff after "IMPORTANT SECTION FOLLOWS"). In my opinion (and I think of everyone else who appears to use NT386GNU and also post to this mailing list) the point of Cygwin is to work as a crutch for Unix people who really, really don't want to use Windows, but are forced for some (probably economic) reason to do so... We want as much Unix and as little Windows as possible, and we're willing to jump through all sorts of hoops to get our way.... Mika # # $Id: README.CYGWIN,v 1.3 2007/07/28 23:43:50 mika Exp $ # ===== Basic instructions ===== If you are just building, not maintaining, just export CYGWIN=1 before compiling. If you are not building as user "mika", you will have to make some changes to Make.defs (please look at that file). ===== From-Scratch Installation ===== Installing this system on Cygwin can be a little tricky. So far, it's only been tested with the old PM3 distribution from Klagenfurt (?). This PM3 comes on 44 "floppies" and is installed in accordance with the instructions (in German) located at http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html Having installed the PM3 distribution, building small, self-contained Modula-3 programs should be no problem. However, it is different with this software distribution. During the build process, tools are built that are used later on in the same build process. For various reasons, m3 "overrides" don't seem to work right on Cygwin/PM3-Klagenfurt, so we build a "distribution" system and m3ship everything. ===== IMPORTANT SECTION FOLLOWS ===== The main thing that has to be done to simplify the work of the build system is to make sure that DOS and Cygwin directory paths match AS MUCH AS POSSIBLE. This is difficult, because by default, Cygwin has a different view of the "root" of the filesystem from the standard DOS view. Running under Cygwin, the Klagenfurt system unfortunately sometimes takes the DOS view and sometimes takes the Cygwin view. The situation is further complicated by the fact that Windows doesn't have proper symbolic links. The saving grace is that Cygwin DOES have proper symbolic links. The solution is therefore to make the directory structure that is desired under DOS and then link to it from within the Cygwin hierarchy. Therefore: Move the users' home directories to C:\home and make the links as follows: Cygwin link DOS equivalent /home -> /cygdrive/c/home C:\cygwin\home -> C:\home etc. The filenames are still occasionally polluted by DOS things like backslashes and drive letters. The scripts in cygwinhacks should take care of most of the remaining problems of this sort. I am not sure this system can be made to work if your system disk is called anything other than C:. Best not to try. (end of README.CYGWIN) Olaf Wagner writes: >Jay, > >I'm not really happy with NT386GNU using PathnameWin32.m3. >In my opininion it should just use the POSIX code, whatever problems >people will have with their installation roots. (These can be avoided >by using the /cygdrive/... equivalents.) >Why don't we just assume that by deafult CM3 is installed in >/usr/local/cm3 as for all other targets (except NT386, of course)? > >One thing that immediately comes to mind is that all paths output >by CM3 programs will contain \ instead of / then and thus be >unusable for simple copy-and-paste, as \ is the escape character >in all POSIX command line tools. So this seems kind of incompatible >to me. > >Olaf > >Quoting Jay : > >> I could be wrong about many things here: >> >> Cygwin fopen and I presume open accepts all of: >> c:\foo, c:/foo, /foo, \foo >> >> /foo and \foo probably have a different meaning between Cygwin and Win32. >> In Win32, /foo and \foo are, well, \foo, on the current drive. >> In Cygwin, /foo is probably /foo at the Cygwin root. >> I'd kind of like to be wrong here, about \foo having different >> meanings between them, since it a common form for me. >> >> Cygwin does not accept c:foo. >> In Win32 c:foo is foo in the current working directory of the C: drive. >> I don't think c:foo is used often, but it does have a meaning. >> >> Now, as well, cm3 has its own Path module, M3Path, but I realized >> tonight it also uses libm3's Pathname module a fair amount. In >> particular, I was having errors "shipping". >> >> This throws a big monkey wrench into where I was going. >> So now, after a bunch of going back and forth on various uncommited >> changes, I have now switched (and commited) NT386GNU to use >> PathnameWin32.m3. To some extent, this strikes at the core of "what >> is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". >> However, remember that Cygwin does appear to accept Win32 paths. >> So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that >> Win32 accepts /foo, is it Posix?) As well, this target still uses >> cygwin1.dll for its all its odd behaviors. It still uses >> open/read/write (again, remember that msvcrt.dll DOES expose these >> SAME functions..I still contend that Win32 is close enough to Posix >> to satisfy almost everyone..and then X Windows can be dealt with >> separately maybe, or Trestle/Win32 fixed). >> >> I have some more testing to do but I think this switch will fly, and >> various other options can go away. >> And I can undo the small amount I had commited. >> I think I'll just send my m3path.m3 diff around and then delete it. >> >> I ended up with a set based approach where host and target have a >> set of dir separaters, volume separaters, and separators (union of >> previous two). These are TINY sets, containing a maximum of three >> characters each, and '/' is always a member of two of them. So a set >> is kind of overkill. But it works out pretty ok. >> >> - Jay >> _________________________________________________________________ >> Need to know the score, the latest news, or you need your >> Hotmail??-get your "fix". >> http://www.msnmobilefix.com/Default.aspx > > > >-- >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Sun Feb 24 20:59:30 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 24 Feb 2008 13:59:30 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> Message-ID: <47C1CCA2.8060503@wichita.edu> Ahh, I get it. This will be much simpler than I thought. Darko wrote: > What I meant to say below is that unpacked structures are aligned > according to the normal rules under Darwin. The problem is that the > packed alignment rules without the change are too restrictive. > > On 24/02/2008, at 4:31 AM, Rodney M. Bates wrote: > >> I guess I misunderstood. I had the idea from the quoted text below >> that MAC OS X needed a mixture >> of lazy and strict alignment. If every platform uses the same >> alignment rules for all types of all >> programs on the platform, then the alignment rule property can just >> be made an additional field of >> the RTPacking.T. >> >> This is much easier to do without compatibility problems, because >> this value is encoded in bits >> in a 32-bit word in pickle headers, with unused bits that are now >> ignored. The alignment strategy >> could just be in another bit. >> >> >> From a post on 2-11: >> --------------------------------------------------------------------------------------------------------- >> >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All other >> structures should use normal alignment to be compatible with C and >> Unix interfaces. The alignment change was implemented to be >> supported only in packed structures as a natural and intuitive way >> to "force" alignment. You could view it as a bug fix to overly >> restrictive alignment rules in packed structures. >> >> >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >> >> > It sounds like all that Mac OS X needs is for _all_ types in an entire >> > program to use the liberal packing rules. Have I understood >> correctly? >> > I would have no grief over that. >> --------------------------------------------------------------------------------------------------------- >> >> >> Darko wrote: >> >>> The alignment rules are particular to a platform, not a type (at >>> least after we get rid of the pragma), so is there no field where >>> we can encode some information about the platform in the pickle >>> header or something? Where is endian stored? >> >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 mika at async.caltech.edu Sun Feb 24 23:24:30 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 Feb 2008 14:24:30 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> Message-ID: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Surely the SPIN people had to do that? I've wanted it a few times, too. Mika =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Once, there was a talk about (original?) CM3 making checked runtime >errors behave like exceptions? >-- >Dragi??a Duri?? From jayk123 at hotmail.com Mon Feb 25 09:13:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:13:50 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: Here is an unnecessarily complete explanation: The problem was Given "a../..", M3Path.FixPath wasn't doing anything. I wanted to fix that. It would collapse "a/.." or ".a/.." or "a./.." correctly, but not "a../.." I know people will disagree as to what is "correct" due to symlinks, but this was/is the behavior. Given input like "../.." it should also leave that alone, because "there is nowhere for it to go". In fixing "a../.." to collapse to nothing or ".", I also broke leaving "../.." alone. I thought the check for "is the element prior to ".." also ".."?" wasn't needed, since they get removed, left to right, and the scan is restarted for every change, but they aren't removed if "there is nowhere to go", so the check is valid. But the check wasn't right. It didn't check for a ".." element, it checked for an element ending in "..". NOW it should be treating them both correctly, as well as not indexing out of bounds for other input as it was doing. I added a check that the previous element is of length 2, and "ends" "..". Yes, I realize that elements ending in ".." but not equal to ".." are rare and not particularly interesting. Windows even has trouble with them: C:\>mkdir a.. C:\>dir a* 02/25/2008 12:11 AM a Huh? C:\>mkdir \\?\c:\a.. C:\>dir a* 02/25/2008 12:11 AM a 02/25/2008 12:12 AM a.. C:\>rmdir a.. C:\>dir a* 02/25/2008 12:12 AM a.. Huh? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.comDate: Sun, 24 Feb 2008 15:58:20 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] Revert cm3 to version 6 days ago Ok, I see:http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-FreeBSD4.html#tr_m3-db-odbcIt really must be:http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Path.m3.diff?r1=1.14;r2=1.15 The error is unable to open "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../odbc/FreeBSD4/.M3EXPORTS" but it should be trying to open: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../../../odbc/FreeBSD4/.M3EXPORTS" or, fixed up: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/FreeBSD4/.M3EXPORTS" My change is making it remove two instances of .. at once or something like that.I still am not reading it fully, but this must be it. Overrides are often/usually "built down" from ROOT, but in this case they are "built up". Anyway I'm off to debug:== package C:\dev2\cm3.2\m3-obliq\obliqrt == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++--- building in NT386GNU ---ignoring ../src/m3overrides/cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB/cygdrive/C/cm3/bin/shobjcodegen: Processing ObValue.ReplObjStd"/cygdrive/C/cm3/pkg/sharedobj/src/sharedobj.tmpl", line 49: quake runtime error: exit 35584: /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB and I have guests coming soon too. :) - Jay > Date: Sun, 24 Feb 2008 16:32:05 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: Revert cm3 to version 6 days ago> > Quoting Jay :> > > Oh darn, inevitably that is not my final answer..> > more like attached..> > Jay,> > the files seem to work OK on my FreeBSD system. But the tinderbox> tests on birch and new have failed, in spite of my CVS revert;> so please don't commit anything until I have found out what is wrong.> It may take some time, because I'm expecting guests soon and won't> be able to do much until tomorrow evening.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000> >> >> > Olaf can you try the attached? Thanks, - Jay> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:31:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:31:47 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: It is easier than today I think, and might be made even easier. Unix doesn't have to be as hard as possible, though I guess I'm a heretic on this point too. Unix seems to be all about making things much harder than necessary. I am using a workaround for at least some scenarios. In particular I have some NTFS junctions and some Cygwin symlinks. Though the symlinks are just for shorter paths and I think unnecessary. Cygwin symlinks: /c => /cygdrive/c /dev2 => /c/dev2 (and then recurse) /cm3 => /c/cm3 (and then recurse) NTFS junctions: (I use sysinternals.com's junction.exe to set these up) \cygdrive\c => c:\ \c\cm3 => c:\cm3 (aka /c/cm3, on current drive, and win32 accepts forward slashes, voila) \c\dev2 => c:\dev2 (aka /c/cdev2, likewise) You could also setup in-memory symlinks I believe with subst and/or DefineDosDevice. This way I can cross build either from either. Just bringing up CM3/Cygwin and "staying there", I don't think requires this. Nor does starting from the distribution I provided,I think. I guess I should test that, and if I am wrong, document these as "officially" needed. (X86_CYGWIN?, X86_MINGWIN? X86_INTERIX, X86_POSIX_CYGWIN, X86_WIN32_MINGWIN, X86_POSIX_INTERIX?) I also do some path conversion in the Python wrappers. I would strongly consider the following: in cm3.exe, set the quake variables INSTALLROOT and ROOT very much like how the Python/sh/Quake code does. Something like: If the environment variable CM3_ROOT is set, set ROOT to it. If the environment variable CM3_INSTALL is set, set INSTALLROOT to it. I wouldn't mind while at it coming up with longer more clear names -- CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. Convert INSTALLROOT and ROOT to what is native to cm3.exe. Possibly write the variables back out to the environment, though that should be not necessary. If M3CONFIG is set in the environment, convert it to what is native cm3.exe. For all this work, only accept full paths. That removes ambiguity since /foo is a valid Win32 path. If the environment variables are not set, CM3_INSTALL can be gleaned from cm3.exe's own path. On Windows this is from GetModuleHandleW(NULL). On other platforms, I guess argv[0]? /Possibly/ by searching $PATH for cm3.exe, but that fails if I run cm3.exe by full path and it isn't in $PATH, so no. CM3_ROOT /maybe/ should not be sniffed out. You could do it by checking for CVS directory in current working directory and then going up until CVS/Repository has no slashes, something like that. Yes, I know that is specific to using CVS, doesn't work if you are sitting elsewhere, doesn't work when another source control system is used, etc. But it is very much correct today and fast enough and when it works, is correct (ok..sitting in another CVS tree?) and makes things just a little easier to use. Automation is the name of the game, right? Otherwise we'd all be programming in assembly or ones and zeros. - Jay > To: wagner at elegosoft.com> Date: Sun, 24 Feb 2008 13:54:34 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Olaf, you're right:> > People who use Cygwin are used to dealing with all kinds of oddities.> > I am here reproducing "README.CYGWIN" from the top level of my M3> project (note the stuff after "IMPORTANT SECTION FOLLOWS"). In my > opinion (and I think of everyone else who appears to use NT386GNU and> also post to this mailing list) the point of Cygwin is to work as a> crutch for Unix people who really, really don't want to use Windows,> but are forced for some (probably economic) reason to do so... We> want as much Unix and as little Windows as possible, and we're willing> to jump through all sorts of hoops to get our way....> > Mika> > > #> # $Id: README.CYGWIN,v 1.3 2007/07/28 23:43:50 mika Exp $> #> > ===== Basic instructions =====> > If you are just building, not maintaining, just > > export CYGWIN=1> > before compiling.> > If you are not building as user "mika", you will have to make some> changes to Make.defs (please look at that file).> > ===== From-Scratch Installation =====> > Installing this system on Cygwin can be a little tricky. So far, it's> only been tested with the old PM3 distribution from Klagenfurt (?).> This PM3 comes on 44 "floppies" and is installed in accordance with the> instructions (in German) located at> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > Having installed the PM3 distribution, building small, self-contained > Modula-3 programs should be no problem.> > However, it is different with this software distribution. During the> build process, tools are built that are used later on in the same build> process. For various reasons, m3 "overrides" don't seem to work right on> Cygwin/PM3-Klagenfurt, so we build a "distribution" system and m3ship> everything.> > ===== IMPORTANT SECTION FOLLOWS =====> > The main thing that has to be done to simplify the work of the build> system is to make sure that DOS and Cygwin directory paths match AS> MUCH AS POSSIBLE. This is difficult, because by default, Cygwin has> a different view of the "root" of the filesystem from the standard> DOS view. Running under Cygwin, the Klagenfurt system unfortunately> sometimes takes the DOS view and sometimes takes the Cygwin view.> The situation is further complicated by the fact that Windows doesn't> have proper symbolic links.> > The saving grace is that Cygwin DOES have proper symbolic links.> The solution is therefore to make the directory structure that is desired> under DOS and then link to it from within the Cygwin hierarchy.> > Therefore:> > Move the users' home directories to > > C:\home> > and make the links as follows:> > Cygwin link DOS equivalent> /home -> /cygdrive/c/home C:\cygwin\home -> C:\home> > etc.> > The filenames are still occasionally polluted by DOS things like> backslashes and drive letters. The scripts in cygwinhacks should take> care of most of the remaining problems of this sort.> > I am not sure this system can be made to work if your system disk> is called anything other than C:. Best not to try.> > (end of README.CYGWIN)> > Olaf Wagner writes:> >Jay,> >> >I'm not really happy with NT386GNU using PathnameWin32.m3.> >In my opininion it should just use the POSIX code, whatever problems> >people will have with their installation roots. (These can be avoided> >by using the /cygdrive/... equivalents.)> >Why don't we just assume that by deafult CM3 is installed in> >/usr/local/cm3 as for all other targets (except NT386, of course)?> >> >One thing that immediately comes to mind is that all paths output> >by CM3 programs will contain \ instead of / then and thus be> >unusable for simple copy-and-paste, as \ is the escape character> >in all POSIX command line tools. So this seems kind of incompatible> >to me.> >> >Olaf> >> >Quoting Jay :> >> >> I could be wrong about many things here:> >>> >> Cygwin fopen and I presume open accepts all of:> >> c:\foo, c:/foo, /foo, \foo> >>> >> /foo and \foo probably have a different meaning between Cygwin and Win32.> >> In Win32, /foo and \foo are, well, \foo, on the current drive.> >> In Cygwin, /foo is probably /foo at the Cygwin root.> >> I'd kind of like to be wrong here, about \foo having different > >> meanings between them, since it a common form for me.> >>> >> Cygwin does not accept c:foo.> >> In Win32 c:foo is foo in the current working directory of the C: drive.> >> I don't think c:foo is used often, but it does have a meaning.> >>> >> Now, as well, cm3 has its own Path module, M3Path, but I realized > >> tonight it also uses libm3's Pathname module a fair amount. In > >> particular, I was having errors "shipping".> >>> >> This throws a big monkey wrench into where I was going.> >> So now, after a bunch of going back and forth on various uncommited > >> changes, I have now switched (and commited) NT386GNU to use > >> PathnameWin32.m3. To some extent, this strikes at the core of "what > >> is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > >> However, remember that Cygwin does appear to accept Win32 paths. > >> So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > >> Win32 accepts /foo, is it Posix?) As well, this target still uses > >> cygwin1.dll for its all its odd behaviors. It still uses > >> open/read/write (again, remember that msvcrt.dll DOES expose these > >> SAME functions..I still contend that Win32 is close enough to Posix > >> to satisfy almost everyone..and then X Windows can be dealt with > >> separately maybe, or Trestle/Win32 fixed).> >>> >> I have some more testing to do but I think this switch will fly, and > >> various other options can go away.> >> And I can undo the small amount I had commited.> >> I think I'll just send my m3path.m3 diff around and then delete it.> >>> >> I ended up with a set based approach where host and target have a > >> set of dir separaters, volume separaters, and separators (union of > >> previous two). These are TINY sets, containing a maximum of three > >> characters each, and '/' is always a member of two of them. So a set > >> is kind of overkill. But it works out pretty ok.> >>> >> - Jay> >> _________________________________________________________________> >> Need to know the score, the latest news, or you need your > >> Hotmail??-get your "fix".> >> http://www.msnmobilefix.com/Default.aspx> >> >> >> >-- > >Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany> >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin> >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:32:56 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:32:56 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: It is easier than THAT today, I meant, otherwise ambiguous and I could have been saying your way is easier than mine. I'm lazy and so I try to make things easy for myself. :) - Jay From: jayk123 at hotmail.comTo: mika at async.caltech.edu; wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] paths..Date: Mon, 25 Feb 2008 08:31:47 +0000 It is easier than today I think, and might be made even easier.Unix doesn't have to be as hard as possible, though I guess I'm a heretic on this point too.Unix seems to be all about making things much harder than necessary. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:33:52 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:33:52 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: got truncated again... Here is an unnecessarily complete explanation: The problem was Given "a../..", M3Path.FixPath wasn't doing anything. I wanted to fix that. It would collapse "a/.." or ".a/.." or "a./.." correctly, but not "a../.." I know people will disagree as to what is "correct" due to symlinks, but this was/is the behavior. Given input like "../.." it should also leave that alone, because "there is nowhere for it to go". In fixing "a../.." to collapse to nothing or ".", I also broke leaving "../.." alone. I thought the check for "is the element prior to ".." also ".."?" wasn't needed, since they get removed, left to right, and the scan is restarted for every change, but they aren't removed if "there is nowhere to go", so the check is valid. But the check wasn't right. It didn't check for a ".." element, it checked for an element ending in "..". NOW it should be treating them both correctly, as well as not indexing out of bounds for other input as it was doing.I added a check that the previous element is of length 2, and "ends" "..". Yes, I realize that elements ending in ".." but not equal to ".." are rare and not particularly interesting.Windows even has trouble with them: C:\>mkdir a.. C:\>dir a* 02/25/2008 12:11 AM a Huh? C:\>mkdir \\?\c:\a.. C:\>dir a* 02/25/2008 12:11 AM a 02/25/2008 12:12 AM a.. C:\>rmdir a.. C:\>dir a* 02/25/2008 12:12 AM a.. Huh? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:40:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:40:10 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: > process. For various reasons, m3 "overrides" don't seem to work right on ps: I believe overrides work in CM3/NT386GNU today. At least I didn't do anything to workaround them not working. buildship and upgrade and make-dist all seem to work and I believe the second two depend on overrides. I have seen overrides vary between using SL and /, but either should always work now. PathnameWin32.m3 and M3Path.m3 always recognize / as a directory separator, which is correct, unless you prefix the paths with \\? in which case it is arguably incorrect. Please do try the distribution I put out there. Or try building it yourself from current source. Thanks. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:50:08 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:50:08 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: This sounds very much how Windows has been but finally changed. It used to be in C++ you could do: try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ else catch (...) { printf("caught exception\n"); } now you can't. Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. The most common one is an "access violation". There's also "stack overflow". And others. They can be raised by code via RaiseException though. There is a similar syntax for catching them -- __try / __except. Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"? In particular, Win32 structured exceptions fall into two or three classes: Someone called RaiseException. These are orderly and reasonable to catch, but rare. (Even if C++ exceptions are implemented via RaiseException.) Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some data somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" corrupt. I suggest a NULL deref might be the third class, but not clear. If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the case, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops. What about integer overflow? I wonder. :) - Jay > To: dragisha at m3w.org> Date: Sun, 24 Feb 2008 14:24:30 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well...> > Surely the SPIN people had to do that?> > I've wanted it a few times, too.> > Mika> > =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:> >Once, there was a talk about (original?) CM3 making checked runtime> >errors behave like exceptions?> >-- > >Dragi??a Duri?? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 15:47:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 14:47:44 +0000 Subject: [M3devel] shipping with overrides? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: I understand that when you build with overrides, you can't ship. "package was built with overrides, not shipping." My question is the opposite. Why can some packages apparently ship despite being built with overrides?For example m3middle? Something obvious? Probably. Something to be debugged? - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 16:12:36 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 15:12:36 +0000 Subject: [M3devel] M3Path.FixPath rewrite? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: M3Path.FixPath had some flaws, mainly: it uses a fixed size array to store the locations of path separators in the presence of too many separators, it'd ignore stuff every occurence of . or .. causes it to restart its work (after removing it) I have written a new version with these aspects fixed. Anyone care to try it out? diff and m3path.m3 attached. There's a small test harness built in, disabled. You can feed strings through the old and new and compare. They don't always match. I think my results are "more correct". Thanks, - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: M3Path.m3 URL: From jayk123 at hotmail.com Mon Feb 25 16:38:38 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 15:38:38 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: I know this area has been brewing under the surface a while. I'll bring it up. :) Here is some apparently typical code: PROCEDURE Escape (nm: TEXT): TEXT = VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; BEGIN IF (nm = NIL) THEN RETURN NIL; END; len := Text.Length (nm); IF (len + len <= NUMBER (buf)) THEN RETURN DoEscape (nm, len, buf); ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + len)^); END; END Escape; PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF CHAR): TEXT = VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; BEGIN Text.SetChars (buf, nm); FOR i := 0 TO len-1 DO IF (buf[i] = BackSlash) THEN INC (n_escapes); END; END; IF (n_escapes = 0) THEN RETURN nm; END; src := len - 1; dest := src + n_escapes; WHILE (src > 0) DO c := buf[src]; DEC (src); buf[dest] := c; DEC (dest); IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); END; END; RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); END DoEscape;Look at how inefficient this is. For a long string it makes a heap allocation, even if in the end it makes no changes to the string. For any length string it copies it out to an array. Then if there are any changes, it copies it again, probably into heap, likely the input immediately becoming garbage. Heap allocation may be fast, but building up garbage and causing more work for the garbage collector I assume is bad. And if the string had no backslashes, it's all a big waste. I assume texts are read only? I know lots of systems have read only strings. There are pluses and minus to them. They can be single-instanced. Some systems with read only strings have another type, such as "StringBuilder" or "StringBuffer". So -- I don't have a specific question, but maybe a mutable string "class" aka "type" is needed?Not necessarily in the language but in m3core or libm3? Maybe it's already there? I just spent a few hours diddling with arrays of chars. Unfortunately they are not resizable. It was not entirely satisfactory. Besides the array I had to pass around a length and a start. Wrapping this up in one record TYPE MutableString= ... might be a good idea. For more efficient read only access, would it be reasonable for the runtime to materialize on-demand 8 bit and 16 bit representations of a string if a user calls some new thing like Text.GetDirectA (t: TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF WIDECHAR? Throw an exception if the string cannot be represented with 8 bit characters? Or use utf8? Besides, I know I'm a big predictable whiner but I like how this works in Windows.. It may not have been as seamless, but it works and it really doesn't tend to break or slow down existing code. roughly: "foo" is an 8 bit string of type char* (or const char* or possibly const char[4]) L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) "L" for "long" aka "wide" Functions must be written to specifically use one or the other. In C++ you can templatize. There is std::string and std::wstring that are template instantiations. Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc. And really there's no point in 8 bit strings. If you have a blob, that's an array of bytes or something, not characters. It works. Utf8 is another seemingly popular route but I think it's a hack. I think mostly people don't touch their code and say, voila, it's utf8, and they only really support the same old English or possibly 8 bit characters (some European characters). Granted, to some extent, this does work, as long as you don't do anything with the string but strlen, strcpy, and some others and pass it to code that does treat it correctly. Still, variably sized encodings seem like a bad idea here, and 16 bits per character seem affordable enough. And yes, I know that Unicode is actually know 20 bits per character and some characters take two wchar_ts but I try to ignore that... And I know there is a lot of existing code, but sometimes there is a need for progress too... Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:13:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:13:05 +0000 Subject: [M3devel] test.. In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: looks like m3commit is broken again... _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:15:34 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:15:34 +0000 Subject: [M3devel] thread.fork getting nil on nt386gnu? In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: any obvious ideas? I'll have to pause for a bit again..Jay at jay-win1 /cygdrive/c/dev2/cm3.2/m3-ui/juno-2/juno-app/NT386GNU/Juno.exe ****** runtime error:*** Thread client error: NIL apply method passed to Thread.Fork!*** file "ThreadWin32.m3", line 578*** 14837 [sig] Juno 3908 c:\dev2\cm3.2\m3-ui\juno-2\juno-app\NT386GNU\Juno.exe: *** fatal error - called with threadlist_ix -1Hangup - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:22:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:22:47 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> References: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Message-ID: This was causing NT386GNU shobjgen to crash so I went ahead and wrapped up all the globals in functions. m3commit isn't working. I'm building linuxlibc6 on birch now. Solaris is probably affected. Darwin and I think FreeBSD are not affected. And some inactive platforms -- HPUX, Irix, Linux aout 1.x. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] utime.i3 and imported dataDate: Wed, 13 Feb 2008 11:01:51 +0000 > From: hosking at cs.purdue.edu> > Aren't these all superseded by gettimeofday?> > I say just not support the global variable access.> > Utime.i3 on other platforms does not have these globals.Could be. I don't know this stuff.. They are currently used though. I didn't happen here by chance..I'll maybe poke around.I guess this is a time to send diffs and get sign off on all platforms.OR fork the file backwards to DateLinuxOld.m3, DateBsdOld.m3, move everyone to it, then fix DateLinux/Bsd to have no data and as people test their platform move forward? And the last guy turn off the lights?(This is a philosophical and real question. The first approach is slower but moves cleanly all at once from good to good. The second approach allows a gradual migration that starts right away and leaves a cluttered history in its wake but arrives at the same place, possibly but not necessarily sooner.) Anyway, my workaround I think is working.. - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 03:19:16 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 25 Feb 2008 18:19:16 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Mon, 25 Feb 2008 08:50:08 GMT." Message-ID: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Jay, Sometimes I wonder if you have never read the Green Book!!! The very first section of the Modula-3 definition, Section 2.1 of the Green Book, talks about the distinction between "checked runtime errors" and "unchecked runtime errors" and ends with the sentence "Unchecked runtime errors can occur only in unsafe modules." If I may make one of those philosophical diversions that so often lead to Language Wars (but in this case isn't intended to), you mentioned something a while back along the lines of (I am not quoting you verbatim) "every line of code is part of an application's interface, because it can cause...a change in memory usage or expose a previously unknown race condition".. The whole point of Modula-3 is that Modula-3 is part of a family of tools, a way of thinking, even, under which this isn't true. If you use the garbage collector alluded to by Knuth, timing changes in your program CANNOT cause it to run out of memory. If you use the Extended Static Checker (coded by some of the same people who did Modula-3), timing changes to your program CANNOT expose unknown race conditions because there ARE no race conditions in your program! And if you use Modula-3 the way you're supposed to---that is, use the safe features almost exclusively and use UNSAFE code so sparingly that it is obviously (i.e., provably) correct, you will have NO unchecked runtime errors! Now it is true that we live in an imperfect world, and that neither any mortal nor any product of any mortal is perfect, but the WHOLE POINT of Modula-3 is to be a stepping-stone to this type of perfection!!!! All of its users are longing to one day be programming in the Elysian Fields where there are no race conditions, heap overflows due to lazy garbage collectors, nor any unchecked runtime errors. Will we ever get there? I don't know. But for me at least, one of the reasons I use Modula-3 is because it tries, and I can see how one might fill in the gaps and get it all the way. I know of no other programming environment that comes to within several orders of magnitude of Modula-3's performance and satisfies the same properties. Integer overflow: the Green Book says that the language catches it. Implementations generally don't, as far as I know. The specification is really only fifty pages long... Mika Jay wrote: >This sounds very much how Windows has been but finally changed. > > It used to be in C++ you could do: > > try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ > else catch (...) { printf("caught exception\n"); } > > now you can't. > Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". > "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. > The most common one is an "access violation". There's also "stack overflow". And others. > They can be raised by code via RaiseException though. > > There is a similar syntax for catching them -- __try / __except. > > Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"? > In particular, Win32 structured exceptions fall into two or three classes: > Someone called RaiseException. These are orderly and reasonable to catch, but rare. > (Even if C++ exceptions are implemented via RaiseException.) > Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) > This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some dat >a somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" >corrupt. I suggest a NULL deref might be the third class, but not clear. > >If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the cas >e, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops. > >What about integer overflow? I wonder. :) > > - Jay From jayk123 at hotmail.com Tue Feb 26 01:36:49 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 00:36:49 +0000 Subject: [M3devel] test? Message-ID: Just testing..mailing lists seem down again.. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 04:01:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 03:01:50 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> References: Your message of "Mon, 25 Feb 2008 08:50:08 GMT." <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Message-ID: Mika, I do need to reread that book, yes. Most of my reading of it was years ago. Yes the odds of me confusing checked and unchecked errors are real. I think I might have speculated as to the way things really are, while talking mainly about how things perhaps are not. However..I still believe the implementation is the interface. I don't see how Modula-3 fixes that. > If you use the garbage collector alluded to by Knuth, timing changes> in your program CANNOT cause it to run out of memory. I didn't mean to necessarily link these things together. Let's say garbage is collected immedately upon it being created. A program still has a certain amount of non-garbage memory allocated at any one time, and that amount might grow or shrink as changes are made to the code. How about this backwards example: Let's say I have some code that does a heap allocation and handles arbitrarily large data. I find it is slow and I replace it with a fixed sized array. Boom, I break anyone using large data. Now, granted, this is a dumb, backwards example. But it is an implementation detail not revealed in the .i3 file. The .i3 file, like, the "binary" interface. If you get those to match, well, great, your stack won't be unbalanced, safe code will be safe, but nothing will necessarily be correct. > If you use the Extended Static Checker (coded by some of the same people > who did Modula-3), timing changes to your program CANNOT expose unknown Well...I'm ignorant of this particular checker. I am familiar with some of the static checking that is ot there. Only recently have I seen any static checking for race conditions. This is against and C and C++ code, mind you. Perhaps they "resisted" static analysis until recently, hard to parse and all that.. Anyway, while I am not an expert on static checking potential and practise, I have seen just an astounding number of "crazy" bugs and I don't see much hope for much automatic bug detection. Most of the "bugs" found by static checking are very basic things, like leaks or forgetting to check an error, and never something particularly high level as to what the code is actually supposed to do. I mean..I'm not sure this is a valid example or not, but let's say I have the functions Plus and Minus, and let's say I'm a terrible typist and I implement Plus with - and Minus with +. What static checking will catch that. Now, yes, I grant, any amount of manual dynamic testing will catch it. But I think the point is valid -- static checking never checks much. Generalized automatic checking never checks much. The best you can do is along the lines of m3-sys/tests -- a small "framework" for "running stuff" and "comparing the output against expected", perhaps being amitious and including "negative tests" (make sure erroneous source code fails to compile and gives a good error message). I guess, to put a positive light on things, the best we can hope for is some sort of composition of larger systems out of available parts that are already well tested and known to work fairly well. However, this is just..like..a fractal. Those available parts are built up out of yet again smaller well tested parts. And so on down the line. And no layer or part is free of bugs. Processors have bugs. Compilers have bugs. "operating systems" (which are really nothing special -- just another bunch of libraries) have bugs. "There are bugs everywhere". "More code => more bugs, even if that code is meant to find bugs, such as assertion failures" => people put in incorrect assertions, oops, they trigger, let's go and remove or loosen the assertion. I just don't see static checking making all that much headway against the tremendous variety of things programmers do wrong. "Safety" is a nice step, get the easy things, the buffer overflows, but that still leaves lots of room for error (look at how my "safe" m3path.m3 broke the tinderbox for example....) I think Modula-3 was very far ahead of its time. I think a lot of systems have caught up. I grant that most of the systems that have caught up might not catch all the way up, they are either not as safe or not as performant. Again, really, I think correctness is about far more than safety, and that implementation is interface, because safety or no safety, code can depend on nearly arbitrary characteristics of the code it uses. Ok, I'm repeating myself now, sorry. I don't think I see an argument here btw. Modula-3 is what it is. It solves some problems. It doesn't do the impossible. Have you used the NT386 system btw? One of the great things about Modula-3 is only parsing the headers once, and a resulting very fast compiler. However on non-NT386 the gcc backend all but ruins this perf. The integrated compiler is just way way way way faster than the gcc backend... you (all) should try it. Gotta go, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika at async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the Green Book!!!> > The very first section of the Modula-3 definition, Section 2.1 of> the Green Book, talks about the distinction between "checked runtime> errors" and "unchecked runtime errors" and ends with the sentence> "Unchecked runtime errors can occur only in unsafe modules."> > If I may make one of those philosophical diversions that so often> lead to Language Wars (but in this case isn't intended to), you> mentioned something a while back along the lines of (I am not quoting> you verbatim) "every line of code is part of an application's> interface, because it can cause...a change in memory usage or expose> a previously unknown race condition"..> > The whole point of Modula-3 is that Modula-3 is part of a family> of tools, a way of thinking, even, under which this isn't true.> > If you use the garbage collector alluded to by Knuth, timing changes> in your program CANNOT cause it to run out of memory.> > If you use the Extended Static Checker (coded by some of the same people> who did Modula-3), timing changes to your program CANNOT expose unknown> race conditions because there ARE no race conditions in your program!> > And if you use Modula-3 the way you're supposed to---that is, use the> safe features almost exclusively and use UNSAFE code so sparingly that> it is obviously (i.e., provably) correct, you will have NO unchecked> runtime errors!> > Now it is true that we live in an imperfect world, and that neither> any mortal nor any product of any mortal is perfect, but the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> perfection!!!! All of its users are longing to one day be programming> in the Elysian Fields where there are no race conditions, heap> overflows due to lazy garbage collectors, nor any unchecked runtime> errors. Will we ever get there? I don't know. But for me at> least, one of the reasons I use Modula-3 is because it tries, and> I can see how one might fill in the gaps and get it all the way.> I know of no other programming environment that comes to within> several orders of magnitude of Modula-3's performance and satisfies> the same properties.> > Integer overflow: the Green Book says that the language catches it.> Implementations generally don't, as far as I know.> > The specification is really only fifty pages long...> > Mika> > Jay wrote:> >This sounds very much how Windows has been but finally changed. > > > > It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ > > else catch (...) { printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". > > "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. > > The most common one is an "access violation". There's also "stack overflow". And others.> > They can be raised by code via RaiseException though.> > > > There is a similar syntax for catching them -- __try / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"?> > In particular, Win32 structured exceptions fall into two or three classes:> > Someone called RaiseException. These are orderly and reasonable to catch, but rare. > > (Even if C++ exceptions are implemented via RaiseException.) > > Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) > > This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some dat> >a somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a NULL deref might be the third class, but not clear.> > > >If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the cas> >e, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonder. :)> > > > - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 04:47:03 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 25 Feb 2008 19:47:03 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." Message-ID: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> I believe the main reason the compiler is slow on most platforms is that it sleeps for 0.1 seconds every time it spawns a process. My private version of the compiler has that sleep taken out and runs probably 20x faster (for a typical compile). Jay, I still say you are ignorant of a huge part of the history of Computer Science---in this you are joined by 99% of people who use computers, by the way. You should in fact not start with the Green Book, but with this: http://www.masswerk.at/algol60/report.htm And reflect upon these words (again, from "The Humble Programmer", Dijkstra's 1972 Turing Award lecture): The fourth project to be mentioned is ALGOL 60. While up to the present day FORTRAN programmers still tend to understand their programming language in terms of the specific implementation they are working with hence the prevalence of octal and hexadecimal dumps, while the definition of LISP is still a curious mixture of what the language means and how the mechanism works, the famous Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine effort to carry abstraction a vital step further and to define a programming language in an implementation-independent way. One could argue that in this respect its authors have been so successful that they have created serious doubts as to whether it could be implemented at all! The report gloriously demonstrated the power of the formal method BNF, now fairly known as Backus-Naur-Form, and the power of carefully phrased English, a least when used by someone as brilliant as Peter Naur. I think that it is fair to say that only very few documents as short as this have had an equally profound influence on the computing community. The ease with which in later years the names ALGOL and ALGOL-like have been used, as an unprotected trade mark, to lend some of its glory to a number of sometimes hardly related younger projects, is a somewhat shocking compliment to its standing. The strength of BNF as a defining device is responsible for what I regard as one of the weaknesses of the language: an over-elaborate and not too systematic syntax could now be crammed into the confines of very few pages. With a device as powerful as BNF, the Report on the Algorithmic Language ALGOL 60 should have been much shorter... [talk about parameter-passing in Algol 60] How large a data structure a given program can process is clearly part of its interface, like so: PROCEDURE A(VAR r : ARRAY OF INTEGER); (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) Whether that particular bit of information can be represented in a machine-readable form or not is open to question, but irrelevant. C and C++ don't get much in the way of static verification not because they have messy syntax but because they have poorly understood (sometimes, plainly undefined, I am told) semantics. And yes that is why they started with Modula-3. The readers and writers (Rd and Wr) libraries, as they came out of SRC, have been statically verified to be entirely free of deadlock and I believe also incorrect data accesses. I was at a talk that Greg Nelson gave about this at Caltech a few years ago, but I don't remember all the details---just that they found a few previously unknown bugs. This is what all those <* LL *> pragmas are all about. The ESC project continued with Java. I think the people are all at Microsoft now, but ESC is still available, I believe both for Modula-3 and Java (I think the Java version is still written in Modula-3). Btw, the example that Greg Nelson showed when he gave his demo (live on a laptop!) *did* catch a problem with + vs. - (well it was an array index that was off by 1, and it was caught statically, but it clearly depended on the checker's knowing about + vs. -). And yes you are right, of course, testing never shows much. Another Dijkstraism (from 1970): Program testing can be used to show the presence of bugs, but never to show their absence! It is clear that if you actually want to be certain your program is correct (and some people do, some of the time), you will have to invest in some sort of formal reasoning. In order for it to be tractable, you need simple languages, languages that are not defined by their implementations (because trying to understand that would be hopeless). If you can do that, you can at least divide your bugs into the categories "application bugs" and "language implementation bugs". It is *not* a feature or shortcoming of Modula-3 that its arithmetic rolls over instead of raising an exception on overflow. The language spec is clear on it: in Modula-3, overflows are to be checked runtime errors. It is a compiler shortcoming (or bug) that they aren't checked. And yes, Modula-3 was far ahead, in exactly the same way that Backus, Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson, Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960. But no, absolutely no one has caught up. The utterly vast majority of people who deal with computers still have absolutely no understanding of how to handle system complexity. I am sure that this sad state of affairs is familiar enough to every reader of this email that I don't have to multiply examples. Finally, I'm really not talking about language features.. safe vs. unsafe, avoidance of bus errors, etc. It's a question of tools of the human mind more than it is a question of compiler implementation and runtime systems---not, where do you want to go today? but, do you UNDERSTAND where you are going today? Remember that programming languages are for HUMANS, not computers. Computers couldn't care less what language you are programming in. In fact they would be "happier" if you just typed in the machine code directly! Mika Jay writes: >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Mika, I do need to reread that book, yes. Most of my reading of it was year= >s ago. >Yes the odds of me confusing checked and unchecked errors are real. I think= > I might have speculated as to the way things really are, while talking mai= >nly about how things perhaps are not. >=20 >However..I still believe the implementation is the interface. >I don't see how Modula-3 fixes that. >=20 >> If you use the garbage collector alluded to by Knuth, timing changes> in = >your program CANNOT cause it to run out of memory. >I didn't mean to necessarily link these things together. >Let's say garbage is collected immedately upon it being created. >A program still has a certain amount of non-garbage memory allocated at any= > one time, and that amount might grow or shrink as changes are made to the = >code. >=20 >How about this backwards example: Let's say I have some code that does a he= >ap allocation and handles arbitrarily large data. I find it is slow and I r= >eplace it with a fixed sized array. Boom, I break anyone using large data. = >Now, granted, this is a dumb, backwards example. But it is an implementatio= >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int= >erface. If you get those to match, well, great, your stack won't be unbalan= >ced, safe code will be safe, but nothing will necessarily be correct. >=20 > > If you use the Extended Static Checker (coded by some of the same people= > > who did Modula-3), timing changes to your program CANNOT expose unknown= >=20 >Well...I'm ignorant of this particular checker. I am familiar with some of = >the static checking that is ot there. Only recently have I seen any static = >checking for race conditions. This is against and C and C++ code, mind you.= > Perhaps they "resisted" static analysis until recently, hard to parse and = >all that.. Anyway, while I am not an expert on static checking potential an= >d practise, I have seen just an astounding number of "crazy" bugs and I don= >'t see much hope for much automatic bug detection. Most of the "bugs" found= > by static checking are very basic things, like leaks or forgetting to chec= >k an error, and never something particularly high level as to what the code= > is actually supposed to do. I mean..I'm not sure this is a valid example o= >r not, but let's say I have the functions Plus and Minus, and let's say I'm= > a terrible typist and I implement Plus with - and Minus with +. What stati= >c checking will catch that. Now, yes, I grant, any amount of manual dynamic= > testing will catch it. But I think the point is valid -- static checking n= >ever checks much. Generalized automatic checking never checks much. The bes= >t you can do is along the lines of m3-sys/tests -- a small "framework" for = >"running stuff" and "comparing the output against expected", perhaps being = >amitious and including "negative tests" (make sure erroneous source code fa= >ils to compile and gives a good error message). >=20 >I guess, to put a positive light on things, the best we can hope for is som= >e sort of composition of larger systems out of available parts that are alr= >eady well tested and known to work fairly well. However, this is just..like= >..a fractal. Those available parts are built up out of yet again smaller we= >ll tested parts. And so on down the line. And no layer or part is free of b= >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which = >are really nothing special -- just another bunch of libraries) have bugs. "= >There are bugs everywhere". "More code =3D> more bugs, even if that code is= > meant to find bugs, such as assertion failures" =3D> people put in incorre= >ct assertions, oops, they trigger, let's go and remove or loosen the assert= >ion. >=20 >I just don't see static checking making all that much headway against the t= >remendous variety of things programmers do wrong. "Safety" is a nice step, = >get the easy things, the buffer overflows, but that still leaves lots of ro= >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp= >le....) >=20 >I think Modula-3 was very far ahead of its time. I think a lot of systems h= >ave caught up. >I grant that most of the systems that have caught up might not catch all th= >e way up, they are either not as safe or not as performant. >=20 >Again, really, I think correctness is about far more than safety, and that = >implementation is interface, because safety or no safety, code can depend o= >n nearly arbitrary characteristics of the code it uses. >=20 >Ok, I'm repeating myself now, sorry. >=20 >I don't think I see an argument here btw. Modula-3 is what it is. It solves= > some problems. It doesn't do the impossible. >=20 >Have you used the NT386 system btw? One of the great things about Modula-3 = >is only parsing the headers once, and a resulting very fast compiler. Howev= >er on non-NT386 the gcc backend all but ruins this perf. The integrated com= >piler is just way way way way faster than the gcc backend... you (all) shou= >ld try it. >=20 >Gotta go, > - Jay > > > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika= >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the= > Green Book!!!> > The very first section of the Modula-3 definition, Sectio= >n 2.1 of> the Green Book, talks about the distinction between "checked runt= >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un= >checked runtime errors can occur only in unsafe modules."> > If I may make = >one of those philosophical diversions that so often> lead to Language Wars = >(but in this case isn't intended to), you> mentioned something a while back= > along the lines of (I am not quoting> you verbatim) "every line of code is= > part of an application's> interface, because it can cause...a change in me= >mory usage or expose> a previously unknown race condition"..> > The whole p= >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t= >hinking, even, under which this isn't true.> > If you use the garbage colle= >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t= >o run out of memory.> > If you use the Extended Static Checker (coded by so= >me of the same people> who did Modula-3), timing changes to your program CA= >NNOT expose unknown> race conditions because there ARE no race conditions i= >n your program!> > And if you use Modula-3 the way you're supposed to---tha= >t is, use the> safe features almost exclusively and use UNSAFE code so spar= >ingly that> it is obviously (i.e., provably) correct, you will have NO unch= >ecked> runtime errors!> > Now it is true that we live in an imperfect world= >, and that neither> any mortal nor any product of any mortal is perfect, bu= >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p= >erfection!!!! All of its users are longing to one day be programming> in th= >e Elysian Fields where there are no race conditions, heap> overflows due to= > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g= >et there? I don't know. But for me at> least, one of the reasons I use Modu= >la-3 is because it tries, and> I can see how one might fill in the gaps and= > get it all the way.> I know of no other programming environment that comes= > to within> several orders of magnitude of Modula-3's performance and satis= >fies> the same properties.> > Integer overflow: the Green Book says that th= >e language catches it.> Implementations generally don't, as far as I know.>= > > The specification is really only fifty pages long...> > Mika> > Jay wrot= >e:> >This sounds very much how Windows has been but finally changed. > > > = >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1= >); } /* access violation, reading from address 1 */ > > else catch (...) { = >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) = >catches all C++ exceptions but not these "Win32 structured exceptions". > >= > "Win32 structured exceptions" are generally "hardware exceptions" made vis= >ible to software. > > The most common one is an "access violation". There's= > also "stack overflow". And others.> > They can be raised by code via Raise= >Exception though.> > > > There is a similar syntax for catching them -- __t= >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly= >" and so more "catchable"?> > In particular, Win32 structured exceptions fa= >ll into two or three classes:> > Someone called RaiseException. These are o= >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i= >mplemented via RaiseException.) > > Someone has some corrupted data and "ac= >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more = >common case, and if you catch such an exception, you have to wonder, uh, so= >me data is corrupt..which data? What can I possily do at this point, given = >that some dat> >a somewhere is corrupt? It could be the heap. It could be t= >he stack. It could be something small that I'm not going to touch. Heck, ma= >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N= >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a= >n adequate job of noticing things as soon as they have gone bad, and not at= > an indeterminate point afterward, that sounds more viable. I suspect this = >might be the cas> >e, as long as you haven't called out to some buggy C cod= >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde= >r. :)> > > > - Jay=20 >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Mika, I do need to reread that book, yes. Most of= > my reading of it was years ago.
>Yes the odds of me confusing checked and unchecked errors are real. I think= > I might have speculated as to the way things really are, while talking mai= >nly about how things perhaps are not.
> 
>However..I still believe the implementation is the interface.
>I don't see how Modula-3 fixes that.
> 
>> If you use the garbage collector alluded to by Knuth, timing changesR>> in your program CANNOT cause it to run out of memory.

>I didn't mean to necessarily link these things together.
>Let's say garbage is collected immedately upon it being created.
>A program still has a certain amount of non-garbage memory allocated at any= > one time, and that amount might grow or shrink as changes are made to the = >code.
> 
>How about this backwards example: Let's say I have some code that does a he= >ap allocation and handles arbitrarily large data. I find it is slow and I r= >eplace it with a fixed sized array. Boom, I break anyone using large data. = >Now, granted, this is a dumb, backwards example. But it is an implementatio= >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int= >erface. If you get those to match, well, great, your stack won't be unbalan= >ced, safe code will be safe, but nothing will necessarily be correct.
> 
> > If you use the Extended Static Checker (coded by some of the sam= >e people
 > who did Modula-3), timing changes to your program C= >ANNOT expose unknown

>Well...I'm ignorant of this particular checker. I am familiar with some of = >the static checking that is ot there. Only recently have I seen any static = >checking for race conditions. This is against and C and C++ code, mind you.= > Perhaps they "resisted" static analysis until recently, hard to parse and = >all that.. Anyway, while I am not an expert on static checking potential an= >d practise, I have seen just an astounding number of "crazy" bugs and I don= >'t see much hope for much automatic bug detection. Most of the "bugs" found= > by static checking are very basic things, like leaks or forgetting to chec= >k an error, and never something particularly high level as to what the code= > is actually supposed to do. I mean..I'm not sure this is a valid example o= >r not, but let's say I have the functions Plus and Minus, and let's say I'm= > a terrible typist and I implement Plus with - and Minus with +. What stati= >c checking will catch that. Now, yes, I grant, any amount of manual dynamic= > testing will catch it. But I think the point is valid -- static checking n= >ever checks much. Generalized automatic checking never checks much. The bes= >t you can do is along the lines of m3-sys/tests -- a small "framework" for = >"running stuff" and "comparing the output against expected", perhaps being = >amitious and including "negative tests" (make sure erroneous source code fa= >ils to compile and gives a good error message).
> 
>I guess, to put a positive light on things, the best we can hope for is som= >e sort of composition of larger systems out of available parts that are alr= >eady well tested and known to work fairly well. However, this is just..like= >..a fractal. Those available parts are built up out of yet again smaller we= >ll tested parts. And so on down the line. And no layer or part is free of b= >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which = >are really nothing special -- just another bunch of libraries) have bugs. "= >There are bugs everywhere". "More code =3D> more bugs, even if that code= > is meant to find bugs, such as assertion failures" =3D> people put in i= >ncorrect assertions, oops, they trigger, let's go and remove or loosen the = >assertion.
> 
>I just don't see static checking making all that much headway against the t= >remendous variety of things programmers do wrong. "Safety" is a nice step, = >get the easy things, the buffer overflows, but that still leaves lots of ro= >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp= >le....)
> 
>I think Modula-3 was very far ahead of its time. I think a lot of systems h= >ave caught up.
>I grant that most of the systems that have caught up might not catch all th= >e way up, they are either not as safe or not as performant.
> 
>Again, really, I think correctness is about far more than safety, and that = >implementation is interface, because safety or no safety, code can depend o= >n nearly arbitrary characteristics of the code it uses.
> 
>Ok, I'm repeating myself now, sorry.
> 
>I don't think I see an argument here btw. Modula-3 is what it is. It solves= > some problems. It doesn't do the impossible.
> 
>Have you used the NT386 system btw? One of the great things about Modula-3 = >is only parsing the headers once, and a resulting very fast compiler. Howev= >er on non-NT386 the gcc backend all but ruins this perf. The integrated com= >piler is just way way way way faster than the gcc backend... you (all) shou= >ld try it.
> 
>Gotta go,
> - Jay


> >
>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18= >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
= >>
> Sometimes I wonder if you have never read the Green Book!!!R>>
> The very first section of the Modula-3 definition, Section = >2.1 of
> the Green Book, talks about the distinction between "checked= > runtime
> errors" and "unchecked runtime errors" and ends with the s= >entence
> "Unchecked runtime errors can occur only in unsafe modules.= >"
>
> If I may make one of those philosophical diversions that= > so often
> lead to Language Wars (but in this case isn't intended to= >), you
> mentioned something a while back along the lines of (I am no= >t quoting
> you verbatim) "every line of code is part of an applicati= >on's
> interface, because it can cause...a change in memory usage or = >expose
> a previously unknown race condition"..
>
> The = >whole point of Modula-3 is that Modula-3 is part of a family
> of too= >ls, a way of thinking, even, under which this isn't true.
>
> = >If you use the garbage collector alluded to by Knuth, timing changes
>= >; in your program CANNOT cause it to run out of memory.
>
> If= > you use the Extended Static Checker (coded by some of the same people
&= >gt; who did Modula-3), timing changes to your program CANNOT expose unknown= >
> race conditions because there ARE no race conditions in your progr= >am!
>
> And if you use Modula-3 the way you're supposed to---t= >hat is, use the
> safe features almost exclusively and use UNSAFE cod= >e so sparingly that
> it is obviously (i.e., provably) correct, you w= >ill have NO unchecked
> runtime errors!
>
> Now it is tr= >ue that we live in an imperfect world, and that neither
> any mortal = >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo= >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All= > of its users are longing to one day be programming
> in the Elysian = >Fields where there are no race conditions, heap
> overflows due to la= >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev= >er get there? I don't know. But for me at
> least, one of the reasons= > I use Modula-3 is because it tries, and
> I can see how one might fi= >ll in the gaps and get it all the way.
> I know of no other programmi= >ng environment that comes to within
> several orders of magnitude of = >Modula-3's performance and satisfies
> the same properties.
> <= >BR>> Integer overflow: the Green Book says that the language catches it.= >
> Implementations generally don't, as far as I know.
>
>= >; The specification is really only fifty pages long...
>
> Mik= >a
>
> Jay wrote:
> >This sounds very much how Windows= > has been but finally changed.
> >
> > It used to be in= > C++ you could do:
> >
> > try { printf("%s\n", (char*)= > 1); } /* access violation, reading from address 1 */
> > else ca= >tch (...) { printf("caught exception\n"); }
> >
> > now= > you can't.
> > Now catch (...) catches all C++ exceptions but no= >t these "Win32 structured exceptions".
> > "Win32 structured exce= >ptions" are generally "hardware exceptions" made visible to software.
&= >gt; > The most common one is an "access violation". There's also "stack = >overflow". And others.
> > They can be raised by code via RaiseExc= >eption though.
> >
> > There is a similar syntax for cat= >ching them -- __try / __except.
> >
> > Now, maybe Modu= >la-3 runtime errors are "more orderly" and so more "catchable"?
> >= >; In particular, Win32 structured exceptions fall into two or three classes= >:
> > Someone called RaiseException. These are orderly and reasona= >ble to catch, but rare.
> > (Even if C++ exceptions are implement= >ed via RaiseException.)
> > Someone has some corrupted data and "= >access violated" (aka: some sort of signal/tap on Unix)
> > This = >is the more common case, and if you catch such an exception, you have to wo= >nder, uh, some data is corrupt..which data? What can I possily do at this p= >oint, given that some dat
> >a somewhere is corrupt? It could be t= >he heap. It could be the stack. It could be something small that I'm not go= >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >> >corrupt. I suggest a NULL deref might be the third class, but not= > clear.
> >
> >If Modula-3 does an adequate job of notic= >ing things as soon as they have gone bad, and not at an indeterminate point= > afterward, that sounds more viable. I suspect this might be the cas
>= >; >e, as long as you haven't called out to some buggy C code or some uns= >afe Modula-3, oops.
> >
> >What about integer overflow? = >I wonder. :)
> >
> > - Jay


Climb to = >the top of the charts!=A0Play the word scramble challenge with star power. = >textlink_jan' target=3D'_new'>Play now! >= > >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- From jayk123 at hotmail.com Tue Feb 26 08:07:49 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 07:07:49 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> References: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> Message-ID: Mika you underestimate me somewhat but maybe not entirely. I have never used Algol.I should do a bit more research. BNF to me is, you know, like a grammar, LALR, LL, yacc, PCCTS, whatever. It is very useful step, a very good way to state what it states.But as I understand only describes syntax and not semantics. I could say is:English: subject verb [and verb]*Jay sits. okJay stands. okJay gallops. Syntactically correct but not semantically. Jay is not a horse.It is not type correct. Programming languages catch these errors usually,you don't need "extended static checking".Or you could be type correct but still wrong:Jay dies and lives. Something has to know that living cannot occur after dying.How do I state that? I think C++ is actually underappreciated here.Stroupstrup alludes to a style of programming where all side affectsare via constructor calls. I believe this is "very functional".I haven't yet seen anyone elaborate on this.Add type safety to that."Jay = Jay->die()" would return a subtype of human_t that does not have the live() method.Type checking can possibly do a lot of this.(sorry this is so morbid, I had to think of operations that could not go in acertain sequqence. I guess a better one would be Jay learns to program and Jay is born.) Being syntactically correct is a necessary first step, and thencomes type safety, and then comes actually doing what is intended. Maybe BNF has more features than I assume. I have been exposed to multiple opposing views, such as: as you say -- programs are for people first, computers second The SICP book was very interesting.. and the contrary -- performance, performance, performance Too much abstraction and you lose touch with the machine that doesultimately have to run your creation and if it is runs it too slowly,well, that does matter. (Humans are not going to run your program after all; they are much too slow.) I have a lot of real world practical experience.Not as much maybe as I should but a lot. > How large a data structure a given program can process is clearly > part of its interface, like so: > PROCEDURE A(VAR r : ARRAY OF INTEGER); > (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) Your example proves my point. The "specification" is a comment written in English.Nothing will check it. It might change. Worse, the level of detail in a commentis totally up to the programmer. If the comment was missing, what would theinterface be? That the function does nothing? I contend that there is no language that can state the complete specification.The language of the implementation comes close, however it then rests on what is below it,and so on down the line. Science has apparently figured out enough that "and so on downthe line" doesn't go all that far. We know the computer is digital, 0s and 1s, we don't haveto talk about how the transistors work to spec a function. I will look into the sleep.Can it not be a, um, a wait? You know, wait specifically for the process to exit?At the same time as reading its stdout and stderr?Actually I have some experience here...It turns out, on Windows, that it is very easy to deadlock writing code like this.There about three simple patterns, one that deadlocks, two that don't. pseudo code: 1)process = CreateProcess();if process not done read some from stdout echo it to my stdout read some from stderr echo it to my stderr This can deadlock.IF the child process ONLY writes to one of stdout or stderr, I think no deadlock.But if it writes to both, can deadlock. 2)process = CreateProcesscreate another thread (or have one already created waiting for work to do)optionally create another thread for symmetry of implementation, but inefficienthave one thread read/echo stderr, the other read/echo stdoutThis won't deadlock. 3)create the process such that stdout and stderr are the samethen just read that one pipe/handle/file/whatever, on one thread I guess, I have to check, I think on Windows you do like WaitForMultipleObjects(2, [pipe and process]).I have to check if the pipe is signaled by having data available. And then I have to look into what Posix offers here.Maybe have NT386GNU not use Posix here, however..having tried this for "serial", having done it with Thread,the various implementation pieces are not always so easily mixed and matched.For example PosixFile wants PosixScheduler, which is not usually "with" ThreadWin32, but I put in a dummy one. Having both FileWin32 and FilePosix available, with one being the revealer of File.T would be good.I think this is a simple restructuring of the code. Knowing the machine model and how your code ends up executing on the machine is not at all a bad thing.Being careful with how large the abstraction layers you build is not a bad thing.Making a compromise between human and computer is not a bad thing.I long ago gave up writting in assembly, after all.However I am constantly viewing assembly, partly by dumb virtue of how my debugger works, butalso partly because there are bugs everywhere and everything you hide from me is an opportunityfor you to hide the bug I am looking for. Every abstraction you build is something that is going to have bugs in it that I'm going to have to debug. The less abstraction, the thinner the layers, the less debugging will be needed. But yet you do absolutely need abstraction. There is this term -- "leaky abstraction".Most abstractions leak underlying details, there it is useful to understand as much of the stack as possible. Yes, I understand, it is important to know what is an implementation detail and what is an interface/behavioralguarantee. They are often blurred. One of the things good about Modula-3 is its "portability". The fact that I can do roughly the same things already on NT386, PPC_DARWIN, PPC_LINUX "keeps my honest".I can fairly readily check my work on three kind of different systems. The counterpoint here however is that at the C level and above, all machines are converging ontwo and only two models -- Windows and Posix.Portability is becoming like English. Or English and French.Rather than come up with some very very broad commonality that you believe will be implementableon forseeable architectures, you merely have to fit only two common cases.Or heck, if Cygwin flies, only one common case.(Btw, AMD64_MINGWIN should be fairly easy to implement today, AMD64_CYGWIN not so much.There are already AMD64 MinGWin distributes. Cygwin is loaded with assembly cod and the FAQ/docsare not optimistic about AMD64. So Cygwin isn't clearly a way forward.The integrated backend of course needs work and should be viable.) Yes I know LL is about static checking of locking, though I don't know how to read/write the pragmas.I also noticed the large or lm3 or whatnot files.I should look into what they can state and check. I relatively recently amassed a fairly large collection of compilers in order to "test portability".Man it is a bit sad. CFront based C++ compilers are awful. Only one return statement per functionor something. Maybe this experiment went overboard and there's a smaller number of interestingmodern tools.. Most of the stuff that is left "undefined" in C is very reasonable to leave undefined.For example, signed integer encoding is not specified.Things like going out of bounds on arrays is probably not specified.The reason is obvious -- because it is expensive to check.I have heard of code accidentally depending on array bounds overflow.Two local variables, one could overflow into the other, accidentally doubling the capacity of the program! > in this you are joined by 99% of people who use computers Equating a PROGRAMMER with 99% of computer USERS is very insulting.Really.The family/relative tech support I do..."click the whatever." "Right click or left click?"I have had that question so many times. Good thing three button mice are not prevalent. :)(and please don't insult whoever asked me that question..) The rude thing to wonder here is something about practicality vs. theory....The Modula-3 is actually squarely in the practical camp.What with having the compiler and garbage collector implemented it, for starters. I have used Scheme btw, and I was very enamored of it.Then I started debugging some of it by stepping through STk.Man every other instruction was a type check. Despite that 99% of the type checksall succeeded, or had even already succeeded against that data.It's a great programming model, but perhaps? too difficult to implement efficiently?I don't know. One hole in my experience is working with or implementing systems that infer types,except as a user of C++ templates, which does involve a significant amount of type inference.But it's not e.g. SML or a high end efficient compilation Scheme/Lisp. Meanwhile, the mailing lists are still down. Later, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s ago.> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> If you use the garbage collector alluded to by Knuth, timing changes> in => >your program CANNOT cause it to run out of memory.> >I didn't mean to necessarily link these things together.> >Let's say garbage is collected immedately upon it being created.> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > If you use the Extended Static Checker (coded by some of the same people=> > > who did Modula-3), timing changes to your program CANNOT expose unknown=> >=20> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.> >=20> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >Gotta go,> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked runtime errors can occur only in unsafe modules."> > If I may make => >one of those philosophical diversions that so often> lead to Language Wars => >(but in this case isn't intended to), you> mentioned something a while back=> > along the lines of (I am not quoting> you verbatim) "every line of code is=> > part of an application's> interface, because it can cause...a change in me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=> >, and that neither> any mortal nor any product of any mortal is perfect, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-3 is because it tries, and> I can see how one might fill in the gaps and=> > get it all the way.> I know of no other programming environment that comes=> > to within> several orders of magnitude of Modula-3's performance and satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >This sounds very much how Windows has been but finally changed. > > > => >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=> >); } /* access violation, reading from address 1 */ > > else catch (...) { => >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) => >catches all C++ exceptions but not these "Win32 structured exceptions". > >=> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more => >common case, and if you catch such an exception, you have to wonder, uh, so=> >me data is corrupt..which data? What can I possily do at this point, given => >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n adequate job of noticing things as soon as they have gone bad, and not at=> > an indeterminate point afterward, that sounds more viable. I suspect this => >might be the cas> >e, as long as you haven't called out to some buggy C cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.
> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.
> > 
> >However..I still believe the implementation is the interface.
> >I don't see how Modula-3 fixes that.
> > 
> >> If you use the garbage collector alluded to by Knuth, timing changes >R>> in your program CANNOT cause it to run out of memory.

> >I didn't mean to necessarily link these things together.
> >Let's say garbage is collected immedately upon it being created.
> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.
> > 
> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.
> > 
> > > If you use the Extended Static Checker (coded by some of the sam=> >e people
 > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown

> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).
> > 
> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.
> > 
> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)
> > 
> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.
> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.
> > 
> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.
> > 
> >Ok, I'm repeating myself now, sorry.
> > 
> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.
> > 
> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.
> > 
> >Gotta go,
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
=> >>
> Sometimes I wonder if you have never read the Green Book!!! >R>>
> The very first section of the Modula-3 definition, Section => >2.1 of
> the Green Book, talks about the distinction between "checked=> > runtime
> errors" and "unchecked runtime errors" and ends with the s=> >entence
> "Unchecked runtime errors can occur only in unsafe modules.=> >"
>
> If I may make one of those philosophical diversions that=> > so often
> lead to Language Wars (but in this case isn't intended to=> >), you
> mentioned something a while back along the lines of (I am no=> >t quoting
> you verbatim) "every line of code is part of an applicati=> >on's
> interface, because it can cause...a change in memory usage or => >expose
> a previously unknown race condition"..
>
> The => >whole point of Modula-3 is that Modula-3 is part of a family
> of too=> >ls, a way of thinking, even, under which this isn't true.
>
> => >If you use the garbage collector alluded to by Knuth, timing changes
>=> >; in your program CANNOT cause it to run out of memory.
>
> If=> > you use the Extended Static Checker (coded by some of the same people
&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> >
> race conditions because there ARE no race conditions in your progr=> >am!
>
> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the
> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that
> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked
> runtime errors!
>
> Now it is tr=> >ue that we live in an imperfect world, and that neither
> any mortal => >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All=> > of its users are longing to one day be programming
> in the Elysian => >Fields where there are no race conditions, heap
> overflows due to la=> >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev=> >er get there? I don't know. But for me at
> least, one of the reasons=> > I use Modula-3 is because it tries, and
> I can see how one might fi=> >ll in the gaps and get it all the way.
> I know of no other programmi=> >ng environment that comes to within
> several orders of magnitude of => >Modula-3's performance and satisfies
> the same properties.
> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> >
> Implementations generally don't, as far as I know.
>
>=> >; The specification is really only fifty pages long...
>
> Mik=> >a
>
> Jay wrote:
> >This sounds very much how Windows=> > has been but finally changed.
> >
> > It used to be in=> > C++ you could do:
> >
> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */
> > else ca=> >tch (...) { printf("caught exception\n"); }
> >
> > now=> > you can't.
> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions".
> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software.
&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.
> > They can be raised by code via RaiseExc=> >eption though.
> >
> > There is a similar syntax for cat=> >ching them -- __try / __except.
> >
> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?
> >=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:
> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare.
> > (Even if C++ exceptions are implement=> >ed via RaiseException.)
> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix)
> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat
> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.
> >
> >If Modula-3 does an adequate job of notic=> >ing things as soon as they have gone bad, and not at an indeterminate point=> > afterward, that sounds more viable. I suspect this might be the cas
>=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.
> >
> >What about integer overflow? => >I wonder. :)
> >
> > - Jay


Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => > >textlink_jan' target=3D'_new'>Play now!> >=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Feb 26 11:00:54 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 26 Feb 2008 11:00:54 +0100 Subject: [M3devel] CM3 package dependicies Message-ID: <1204020054.7354.2.camel@hias.m3w.org> I am trying to figure out systematic way to map dependicies of packages so I can make nice hierarchy for RPM building... It's not too hard to map it out from m3makefiles, but it will be much better if someone already solved it :). Is there such a map already out there? TIA, dd -- Dragi?a Duri? From wagner at elegosoft.com Tue Feb 26 11:36:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:36:07 +0100 Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Quoting Jay : > M3Path.FixPath had some flaws, mainly: it uses a fixed size array > to store the locations of path separators in the presence of too > many separators, it'd ignore stuff every occurence of . or .. > causes it to restart its work (after removing it) > I have written a new version with these aspects fixed. > Anyone care to try it out? > diff and m3path.m3 attached. > There's a small test harness built in, disabled. > You can feed strings through the old and new and compare. > They don't always match. I think my results are "more correct". Sorry, it will take some time till I can test these. Why don't you add the test to the package test framework in m3-sys/cm3/tests/src/TestM3Path or similar? Provide a list of input paths and expected output in files; this will make things easier to understand for others. If you add the tests first and wait one day until checking in your change we can see the impacts in the package test results in our tinderbox. Generally I think we should start adding tests for everything we change; there's so much breakage that can be avoided this 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 wagner at elegosoft.com Tue Feb 26 11:45:51 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:45:51 +0100 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <20080226114551.2b0icwj0g4ocw4wg@mail.elegosoft.com> Quoting Jay : > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > I assume texts are read only? Yes. > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed?Not necessarily in the language but in > m3core or libm3? > Maybe it's already there? For string construction you can use TextWr.T. I wouldn't object to a mutable string type as an extension though; but it won't be too easy to design. Unless you are willing to suggest some interface, we should just add this issue to the long-term TODO list. I'd rather prefer getting everything more stable again. The more tests I try to add to the regression, the more problems show up :-/ Olaf > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > _________________________________________________________________ > Helping your favorite cause is as easy as instant messaging. You IM, we give. > http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 26 11:55:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:55:09 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: <1204020054.7354.2.camel@hias.m3w.org> References: <1204020054.7354.2.camel@hias.m3w.org> Message-ID: <20080226115509.oqmdrn0ruo00gwog@mail.elegosoft.com> Quoting Dragi?a Duri? : > I am trying to figure out systematic way to map dependicies of packages > so I can make nice hierarchy for RPM building... It's not too hard to > map it out from m3makefiles, but it will be much better if someone > already solved it :). Is there such a map already out there? Elego ComPact had programs to extract package dependencies (m3dep) and build dependency graphs for projects. I had already started to add some of the old stuff to my local CM3 workspace, but it will take some time until it's ready to commit. I'm currently stuck in libm3 tests automation. I was thinking of adding a simplified and M3-specific version of the ComPact project manager as alternative or replacement to the various build scripts. That's still some work though, and I haven't got much 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 hendrik at topoi.pooq.com Tue Feb 26 17:33:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 26 Feb 2008 11:33:12 -0500 Subject: [M3devel] Do I remember well... In-Reply-To: References: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Message-ID: <20080226163312.GA14499@topoi.pooq.com> On Tue, Feb 26, 2008 at 03:01:50AM +0000, Jay wrote: > > I just don't see static checking making all that much headway against the tremendous variety of things programmers do wrong. "Safety" is a nice step, get the easy things, the buffer overflows, but that still leaves lots of room for error (look at how my "safe" m3path.m3 broke the tinderbox for example....) Static checking is a huge help. Every error caught by a static check is an error clearly and effectively reported to you. You don't have to spend time analysing the run-time behaviour of your program to figure out what's wrong. Granted, there are still lots of things to do wrong. Run-time checks (with garbage collection) help further by enforcing the abstract-machine model of the language. This means that you never have wild pointers or out-of-bounds subscripts in a data structure in one part of a program wreaking havoc on an unrelated part. And those bugs can take *days* to track down. No. These things don't solve all problems. They don't ensure program correctness. But they sure make it easy to track down most problems. -- hendrik From jayk123 at hotmail.com Tue Feb 26 18:39:06 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 17:39:06 +0000 Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite? In-Reply-To: <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: I can't argue adding tests per change is a good idea. I was on a team where at least every bug fix had to come with an automatic regression test, if not every initial change, though of course, you could do the second. My problem historically has been lack of a framework -- how to write tests, how to run them, how to verify them, how to debug them. m3-sys\m3tests appears to be a plenty adequate framework for locally authoring, running, verifying, debugging, plus the tinderbox for ongoing status (not that, as far as I know, the tinderbox is debuggable in-situ, but still, this is plenty). I submitted the change but disabled. It's now a very small diff to enable What is the story on exposing internals to testing though? I see several options, all with pluses and minus: Expose more stuff in the .i3 file. Possibly with names like "Internal" or "Test" in them. Not great but easy and works. Invoke test code from module initialization having checked Params for M3testfoo or such. Not great but easy and often works. Adds unnecessary code to the runtime. Getting better I think: Add FooInternal.i3 or FooTest.i3. Export it from Foo.m3. I guess even to the pkg store? Call it from the text executable (also want to call FooTest.m3). This still exposes internals to callers, but at least with a clear distinction of what is internal or not. I guess another name here is FooFriend.i3. For that matter, split off the testable code into FooTest.m3. Same thing? Somehow "preprocess" the code to extract parts you want to call from test code. I'm not keen on designing a preprocessor. Aha, combine the last few? Split up Foo.m3 into FooTest.m3 and Foo.m3. Both exports only parts of Foo.i3, which is unchanged. Add FooTest.i3 that is empty? "Preprocessing" becomes a) copy an .m3 file b) replace an .i3 file (FooTest.i3)? There, I designed preprocessing, as file copying. There's also the matter of chosing the test cases that matter and not just a bunch of random strings that are obviously handled correctly but I guess just err toward throwing in more strings. - Jay > Date: Tue, 26 Feb 2008 11:36:07 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite?> > Quoting Jay :> > > M3Path.FixPath had some flaws, mainly: it uses a fixed size array > > to store the locations of path separators in the presence of too > > many separators, it'd ignore stuff every occurence of . or .. > > causes it to restart its work (after removing it)> > I have written a new version with these aspects fixed.> > Anyone care to try it out?> > diff and m3path.m3 attached.> > There's a small test harness built in, disabled.> > You can feed strings through the old and new and compare.> > They don't always match. I think my results are "more correct".> > Sorry, it will take some time till I can test these.> > Why don't you add the test to the package test framework> in m3-sys/cm3/tests/src/TestM3Path or similar?> Provide a list of input paths and expected output in files;> this will make things easier to understand for others.> If you add the tests first and wait one day until checking in> your change we can see the impacts in the package test results> in our tinderbox.> > Generally I think we should start adding tests for everything we> change; there's so much breakage that can be avoided this 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> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 18:47:31 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 17:47:31 +0000 Subject: [M3devel] cross "compiling" In-Reply-To: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> References: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> Message-ID: This may be obvious to everyone and so inadequate as to be useless, but I just had a minor idea and proved it correct. Even if you don't have a backend, C compiler, linker, etc, you can still compile the Modula-3 code for any target from any target. If you just put return 0 in the config file for backend, compile_c, link, make_lib, assembly, you can at least run the front/middle ends. For example I just compiled m3core and libm3 for Solaris. That would have caught my DatePosix.m3 error, though that sort of change was maybe one that just can't be commited without an available machine. (I'm still not sure how to do these things. You can only change what you have, or send diffs around and wait for the all clear, or you can make a best effort and hope..) Obviously it only affords a certain minimal amount of checking. But it is perhaps something. IN FACT...maybe it is enough testing that the tinderboxes should do it, for all platforms deemed "supported"? I don't think you can ship, but you can buildlocal. (I built libm3, depends on m3core). I'll push this a bit further. IF this is deemed useful, maybe a compiler switch? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Feb 26 19:34:28 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 26 Feb 2008 12:34:28 -0600 Subject: [M3devel] Is the climate right for a new promotion? Message-ID: <47C45BB4.40009@wichita.edu> I have been thinking lately that the climate might be right for a new attempt to promote Modula 3. I see two major trends and a small one that suggest this. Fist, probably nearly once week on the average, I see new articles that say that software developers are not prepared to utilize the now- proliferating multi-core processors. This actually greatly surprises me, because I had lots of exposure, decades ago, to all the concurrent programming stuff--threads, synchronization, scheduling, etc. But apparently, most programmers have been doing strictly sequential programming, and I have to admit, I myself only use concurrent programming techniques a minority of the time. In Modula-3, we have a language that already has better support than most, and certainly better than all the popular languages. Moreover, the implementation is out if front too, with Tony's recent thread and GC work for multi-processors. There are also a few articles out there that say, in effect, it is hopeless to implement threads and synchronization correctly as library code on top of existing C/C++. Second, the expansion of the internet and its vulnerability to automated attacks from anywhere in the world has greatly upped the ante on correctness of software. Before, it was enough if a program handled all the realistic cases that a reasonable user would present it with. Now, the whole theoretical space of inputs has to be handled with at least some level of correctness to avoid vulnerabilities. 1000-byte passwords are the standard example. All this means the limits of testing as a means of finding the bugs are a far greater obstacle than they once were. This makes the time right for another push toward static languages, which were somewhat of a popular flop the first time. Third, and perhaps rather more narrow, the developers of safety- critical software are reexamining the value of testing in the light of various close-calls, for example in airplanes. They are starting to look again at static methods. We have a language which, though little-known, is already designed and implemented and has a lot of convincing history. It has a lot of things that can be promoted. Aside from good thread support and the best safety properties around, it is much simpler than almost anything, yet more powerful than almost anything. A serious push would probably need the support of some large company or organization. But I think the climate is better than it has been in decades, and the technical arguments are very strong. -- ------------------------------------------------------------- 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 Tue Feb 26 19:19:53 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:19:53 +0000 Subject: [M3devel] cross "compiling" In-Reply-To: References: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> Message-ID: e.g. I can get this far in scripts/python/do-cm3-all.py: --- building in SOLgnu --- <== SOLgnu /cygdrive/C/dev2/cm3.2/m3-tools/m3bundle/SOLgnu/m3bundle -name B -F/cygdrive/c/DOCUME~1/Jay/LOCALS~1/Temp/qkunable to open file for reading: ../SOLgnu/B.i3: errno=2unable to open file for reading: ../SOLgnu/B.m3: errno=2 and yes I understand the problem and I think you can trivially override it by using the "correct" host m3bundle instead of the "just built" one. (might have had to make a change to skip tapi) (and I should be able to run X86_SOLARIS in a virtual machine...) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 17:47:31 +0000Subject: [M3devel] cross "compiling" This may be obvious to everyone and so inadequate as to be useless, but I just had a minor idea and proved it correct. Even if you don't have a backend, C compiler, linker, etc, you can still compile the Modula-3 code for any target from any target. If you just put return 0 in the config file for backend, compile_c, link, make_lib, assembly, you can at least run the front/middle ends. For example I just compiled m3core and libm3 for Solaris. That would have caught my DatePosix.m3 error, though that sort of change was maybe one that just can't be commited without an available machine. (I'm still not sure how to do these things. You can only change what you have, or send diffs around and wait for the all clear, or you can make a best effort and hope..) Obviously it only affords a certain minimal amount of checking.But it is perhaps something. IN FACT...maybe it is enough testing that the tinderboxes should do it, for all platforms deemed "supported"?I don't think you can ship, but you can buildlocal. (I built libm3, depends on m3core). I'll push this a bit further. IF this is deemed useful, maybe a compiler switch? - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 19:29:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 13:29:28 -0500 Subject: [M3devel] thread.fork getting nil on nt386gnu? In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: <6346DE25-6495-49D0-A990-F48B989218AC@cs.purdue.edu> Looks like a corrupted/uninitialized type (method table contains a NIL pointer...). 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 Feb 25, 2008, at 1:15 PM, Jay wrote: > any obvious ideas? I'll have to pause for a bit again.. > > Jay at jay-win1 /cygdrive/c/dev2/cm3.2/m3-ui/juno-2/juno-app/NT386GNU/ > Juno.exe > > *** > *** runtime error: > *** Thread client error: NIL apply method passed to Thread.Fork! > *** file "ThreadWin32.m3", line 578 > *** > 14837 [sig] Juno 3908 c:\dev2\cm3.2\m3-ui\juno-2\juno-app\NT386GNU > \Juno.exe: * > ** fatal error - called with threadlist_ix -1 > Hangup > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 19:35:33 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:35:33 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> References: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> Message-ID: Hey I accidentally mostly confirmed this. I changed the backend to just "touch" and it too is slow. Now, granted, vfork in Cygwin is the same as fork, and does a big memory copy, so it could be that running anything in Cygwin is slow. But I could compare to other platforms..or just try removing it. Removing this is easy, at least for PTHREADS, right? And "user threads", can, at worst, do the sleep in their specific code? I think it might be good to run cm3cg and maybe as only once per directory besides, with all the files at once, or at least a few at time, or with a response file. Thanks, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s ago.> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> If you use the garbage collector alluded to by Knuth, timing changes> in => >your program CANNOT cause it to run out of memory.> >I didn't mean to necessarily link these things together.> >Let's say garbage is collected immedately upon it being created.> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > If you use the Extended Static Checker (coded by some of the same people=> > > who did Modula-3), timing changes to your program CANNOT expose unknown=> >=20> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.> >=20> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >Gotta go,> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked runtime errors can occur only in unsafe modules."> > If I may make => >one of those philosophical diversions that so often> lead to Language Wars => >(but in this case isn't intended to), you> mentioned something a while back=> > along the lines of (I am not quoting> you verbatim) "every line of code is=> > part of an application's> interface, because it can cause...a change in me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=> >, and that neither> any mortal nor any product of any mortal is perfect, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-3 is because it tries, and> I can see how one might fill in the gaps and=> > get it all the way.> I know of no other programming environment that comes=> > to within> several orders of magnitude of Modula-3's performance and satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >This sounds very much how Windows has been but finally changed. > > > => >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=> >); } /* access violation, reading from address 1 */ > > else catch (...) { => >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) => >catches all C++ exceptions but not these "Win32 structured exceptions". > >=> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more => >common case, and if you catch such an exception, you have to wonder, uh, so=> >me data is corrupt..which data? What can I possily do at this point, given => >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n adequate job of noticing things as soon as they have gone bad, and not at=> > an indeterminate point afterward, that sounds more viable. I suspect this => >might be the cas> >e, as long as you haven't called out to some buggy C cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.
> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.
> > 
> >However..I still believe the implementation is the interface.
> >I don't see how Modula-3 fixes that.
> > 
> >> If you use the garbage collector alluded to by Knuth, timing changes >R>> in your program CANNOT cause it to run out of memory.

> >I didn't mean to necessarily link these things together.
> >Let's say garbage is collected immedately upon it being created.
> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.
> > 
> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.
> > 
> > > If you use the Extended Static Checker (coded by some of the sam=> >e people
 > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown

> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).
> > 
> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.
> > 
> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)
> > 
> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.
> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.
> > 
> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.
> > 
> >Ok, I'm repeating myself now, sorry.
> > 
> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.
> > 
> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.
> > 
> >Gotta go,
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
=> >>
> Sometimes I wonder if you have never read the Green Book!!! >R>>
> The very first section of the Modula-3 definition, Section => >2.1 of
> the Green Book, talks about the distinction between "checked=> > runtime
> errors" and "unchecked runtime errors" and ends with the s=> >entence
> "Unchecked runtime errors can occur only in unsafe modules.=> >"
>
> If I may make one of those philosophical diversions that=> > so often
> lead to Language Wars (but in this case isn't intended to=> >), you
> mentioned something a while back along the lines of (I am no=> >t quoting
> you verbatim) "every line of code is part of an applicati=> >on's
> interface, because it can cause...a change in memory usage or => >expose
> a previously unknown race condition"..
>
> The => >whole point of Modula-3 is that Modula-3 is part of a family
> of too=> >ls, a way of thinking, even, under which this isn't true.
>
> => >If you use the garbage collector alluded to by Knuth, timing changes
>=> >; in your program CANNOT cause it to run out of memory.
>
> If=> > you use the Extended Static Checker (coded by some of the same people
&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> >
> race conditions because there ARE no race conditions in your progr=> >am!
>
> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the
> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that
> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked
> runtime errors!
>
> Now it is tr=> >ue that we live in an imperfect world, and that neither
> any mortal => >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All=> > of its users are longing to one day be programming
> in the Elysian => >Fields where there are no race conditions, heap
> overflows due to la=> >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev=> >er get there? I don't know. But for me at
> least, one of the reasons=> > I use Modula-3 is because it tries, and
> I can see how one might fi=> >ll in the gaps and get it all the way.
> I know of no other programmi=> >ng environment that comes to within
> several orders of magnitude of => >Modula-3's performance and satisfies
> the same properties.
> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> >
> Implementations generally don't, as far as I know.
>
>=> >; The specification is really only fifty pages long...
>
> Mik=> >a
>
> Jay wrote:
> >This sounds very much how Windows=> > has been but finally changed.
> >
> > It used to be in=> > C++ you could do:
> >
> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */
> > else ca=> >tch (...) { printf("caught exception\n"); }
> >
> > now=> > you can't.
> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions".
> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software.
&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.
> > They can be raised by code via RaiseExc=> >eption though.
> >
> > There is a similar syntax for cat=> >ching them -- __try / __except.
> >
> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?
> >=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:
> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare.
> > (Even if C++ exceptions are implement=> >ed via RaiseException.)
> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix)
> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat
> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.
> >
> >If Modula-3 does an adequate job of notic=> >ing things as soon as they have gone bad, and not at an indeterminate point=> > afterward, that sounds more viable. I suspect this might be the cas
>=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.
> >
> >What about integer overflow? => >I wonder. :)
> >
> > - Jay


Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => > >textlink_jan' target=3D'_new'>Play now!> >=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 19:53:58 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:53:58 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types. specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199*** Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 20:22:57 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 26 Feb 2008 11:22:57 -0800 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: Your message of "Tue, 26 Feb 2008 11:45:51 +0100." <20080226114551.2b0icwj0g4ocw4wg@mail.elegosoft.com> Message-ID: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Olaf Wagner writes: >Quoting Jay : > >> I know this area has been brewing under the surface a while. >> I'll bring it up. :) >> >> I assume texts are read only? > >Yes. > >> I know lots of systems have read only strings. >> There are pluses and minus to them. They can be single-instanced. >> Some systems with read only strings have another type, such as >> "StringBuilder" or "StringBuffer". >> So -- I don't have a specific question, but maybe a mutable string >> "class" aka "type" is needed?Not necessarily in the language but in >> m3core or libm3? >> Maybe it's already there? CharSeq.T? From jayk123 at hotmail.com Tue Feb 26 20:53:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 19:53:24 +0000 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: I haven't tested this but it looks very suspicious.. When targeting 64 bit targets, the compiler thinks [-1 .. 1] is empty. When compiling things like "compare" functions. I didn't debug it but just looked at the code. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.4 diff -r1.4 TInt.i3 26c26 < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; --- > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff}}; another fix might be: > MOne = Int{1, IBytes{16_ff}}; IBytes used to be 16 bit integers but now is 8 bit integers. PM3 has: Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; which seems adequate for what is likely going on in these parts. I believe ".." fills with zeros, not the previous value. Also, is this objectionable? RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v retrieving revision 1.2 diff -r1.2 TextLiteral.i3 15c15 < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; --- > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - 32; *) Maybe. The 32 bit compiler doesn't like such large types (that follow from the use of this). Maybe preferable to allow 32 bit hosted compiler to allow 64 bit sized types? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 18:53:58 +0000Subject: [M3devel] tangential 64 bit... alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 20:57:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 19:57:20 +0000 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Hm, I don't think that fixes it actually. I'll have to dig in later, if highlighting the problem doesn't make it obvious to others.. What was there didn't look right for 32 bits even, but probably is for some reason.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 19:53:24 +0000Subject: [M3devel] 64 bit fixes? I haven't tested this but it looks very suspicious.. When targeting 64 bit targets, the compiler thinks [-1 .. 1] is empty. When compiling things like "compare" functions. I didn't debug it but just looked at the code. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.4 diff -r1.4 TInt.i3 26c26 < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; --- > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff}}; another fix might be: > MOne = Int{1, IBytes{16_ff}}; IBytes used to be 16 bit integers but now is 8 bit integers. PM3 has: Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; which seems adequate for what is likely going on in these parts. I believe ".." fills with zeros, not the previous value. Also, is this objectionable? RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v retrieving revision 1.2 diff -r1.2 TextLiteral.i3 15c15 < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; --- > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - 32; *) Maybe. The 32 bit compiler doesn't like such large types (that follow from the use of this). Maybe preferable to allow 32 bit hosted compiler to allow 64 bit sized types? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 18:53:58 +0000Subject: [M3devel] tangential 64 bit... alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 21:14:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 15:14:18 -0500 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64- bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: > alpha/osf doesn't work because basictypes/ctypes has a problem with > the 32bit or 64bit types. > specifically "unsigned long" is "empty" for some reason and many > errors cascade from that. > > if you change: > unsigned_int = [16_0 .. 16_ffffffff]; > to > unsigned_int = [16_0 .. 16_fffffffe]; > > you get: > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/TWord.m3", line 199 > *** > > Presumably fixing this first problem is the first step in any "real" > 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem > should just be fixed as a matter of course. > > I know this is the least of anyone's concerns.. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 21:16:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 15:16:47 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: ARRAY OF CHAR/WIDECHAR? These are available in the various Text implementations. For exampe, Text8.T.contents. One can freely mutate these at leisure and the higher-level text will appear to change! On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > Olaf Wagner writes: >> Quoting Jay : >> >>> I know this area has been brewing under the surface a while. >>> I'll bring it up. :) >>> >>> I assume texts are read only? >> >> Yes. >> >>> I know lots of systems have read only strings. >>> There are pluses and minus to them. They can be single-instanced. >>> Some systems with read only strings have another type, such as >>> "StringBuilder" or "StringBuffer". >>> So -- I don't have a specific question, but maybe a mutable string >>> "class" aka "type" is needed?Not necessarily in the language but in >>> m3core or libm3? >>> Maybe it's already there? > > CharSeq.T? From jayk123 at hotmail.com Tue Feb 26 21:34:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:34:51 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Tony..are you sure..I'm not sure what I said is true. It seems clear that the host integer size is well abstracted while interpreting target numbers. I am more certain that [-1 .. 1] is empty, and this is likely a problem in TInt.Subtract.. PROCEDURE Add (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); carry := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO carry := a.x[i] + b.x[i] + carry; r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign # b_sign) OR (a_sign = r_sign); END Add; PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); borrow := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO borrow := a.x[i] - b.x[i] - borrow; r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign = b_sign) OR (a_sign = r_sign); END Subtract; Is it not adequate to treat carry and borrow as one it, zero or non-zero? Thinking in decimal about addition -- 9 + 9 = 18. You can never overflow to 20, 30, 40, etc. For substraction 0 - 9 = -9, never -10 or lower. However "1" is a full decimal digit, not a bit. In this case, the digits are bytes. Aha, so maybe the problem is the "and"? Let's check pm3 and decm3 3.6 again.. No, pm3 has the and too.. hm. I have to refresh some of my bit twiddling algorithms.. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 15:14:18 -0500 Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64-bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 21:35:56 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:35:56 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: Is that legal or is that subverting things? It depends on the context? Can the pointers be to read only memory in the code? - Jay > From: hosking at cs.purdue.edu> To: mika at async.caltech.edu> Date: Tue, 26 Feb 2008 15:16:47 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays?> > ARRAY OF CHAR/WIDECHAR?> > These are available in the various Text implementations. For exampe, > Text8.T.contents. One can freely mutate these at leisure and the > higher-level text will appear to change!> > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote:> > > Olaf Wagner writes:> >> Quoting Jay :> >>> >>> I know this area has been brewing under the surface a while.> >>> I'll bring it up. :)> >>>> >>> I assume texts are read only?> >>> >> Yes.> >>> >>> I know lots of systems have read only strings.> >>> There are pluses and minus to them. They can be single-instanced.> >>> Some systems with read only strings have another type, such as> >>> "StringBuilder" or "StringBuffer".> >>> So -- I don't have a specific question, but maybe a mutable string> >>> "class" aka "type" is needed?Not necessarily in the language but in> >>> m3core or libm3?> >>> Maybe it's already there?> >> > CharSeq.T?> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 21:56:31 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:56:31 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Well I was lazy and did some math in the debugger and indeed one bit of carry or overflow is adequate, for addition and subtraction. You can do better with multiplicatio..and division I'd have to think a lot more about. It is an odd inconsistency between the Add and Subtract code below though.. I guess the reason is that carry will be 0 or 1, but borrow will be 0 or -1 and you want to convert -1 to +1. As well, carry/borrow should be sign extended if you run out of bits, so the -1 is used. It probably could be: add: < r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); > carry := ORD (carry # 0); r.x[i] := carry; subtract: < r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1);> if borrow # 0 then r.x[i] := Mask; borrow := 1; end no major difference. ? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 20:34:51 +0000 Tony..are you sure..I'm not sure what I said is true.It seems clear that the host integer size is well abstracted while interpreting target numbers. I am more certain that [-1 .. 1] is empty, and this is likely a problem in TInt.Subtract.. PROCEDURE Add (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); carry := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO carry := a.x[i] + b.x[i] + carry; r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign # b_sign) OR (a_sign = r_sign); END Add; PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); borrow := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO borrow := a.x[i] - b.x[i] - borrow; r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign = b_sign) OR (a_sign = r_sign); END Subtract;Is it not adequate to treat carry and borrow as one it, zero or non-zero?Thinking in decimal about addition -- 9 + 9 = 18.You can never overflow to 20, 30, 40, etc. For substraction 0 - 9 = -9, never -10 or lower. However "1" is a full decimal digit, not a bit.In this case, the digits are bytes. Aha, so maybe the problem is the "and"? Let's check pm3 and decm3 3.6 again..No, pm3 has the and too.. hm. I have to refresh some of my bit twiddling algorithms.. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 15:14:18 -0500 Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64-bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Feb 26 22:01:22 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 26 Feb 2008 16:01:22 -0500 Subject: [M3devel] volume of cm3-related email traffic In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: <47C437CE.1E75.00D7.1@scires.com> I appreciate all the work everyone is doing these days on cm3, but I am having a problem I'd like to describe. I'm getting a large number of cm3-related email messages relayed to me each day. In many cases, I'm getting two copies of each message because folks are also addressing the message to me in addition to the m3devel list. The email address I've put on the m3devel and m3commit lists is my work email address. So, the large number of messages is now interfering with my job. In the past, this wasn't a problem because there weren't very many messages. I know I could change my email address for these mail lists to a private home mailbox, but I would not be able to check this box as frequently. Before I take this action, here are some suggestions I have: 1. Don't include the original sender on your reply; instead, just address to m3devel [I know I've been guilty about just lazily hitting the reply button without deleting the extra addresses, so this suggestion applies to me as well.] 2. Try not to use m3devel as a blog for a steady-stream of thought. Maybe we should setup a blog or something for this type of activity. 3. Try to think through and test your changes throughly to cut down on the number of commits. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Feb 26 22:28:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 26 Feb 2008 22:28:56 +0100 (CET) Subject: [M3devel] Is the climate right for a new promotion? In-Reply-To: <47C45BB4.40009@wichita.edu> References: <47C45BB4.40009@wichita.edu> Message-ID: On Tue, 26 Feb 2008, Rodney M. Bates wrote: > I have been thinking lately that the climate might be right for a new > attempt to promote Modula 3. I see two major trends and a small one > that suggest this. Promoting Modula-3 is always a good idea. But competition is hard. There are Ada and Eiffel which also follow the safety approach, but are still close to common imperative thinking. But also the Haskell community claims that it has the answer to safety issues and to parallelity. In functional programming you get more guarantees for free, but you have to pay with efficiency. However, there is constant progress in this respect. From my perspective, Modula-3's selling points against Ada and Eiffel are (relative) simplicity, and compared with functional programming Modula-3 may attract people by a conservative (imperative) programming style. From rcoleburn at scires.com Tue Feb 26 22:39:06 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 26 Feb 2008 16:39:06 -0500 Subject: [M3devel] CM3 package dependicies In-Reply-To: <1204020054.7354.2.camel@hias.m3w.org> References: <1204020054.7354.2.camel@hias.m3w.org> Message-ID: <47C440A7.1E75.00D7.1@scires.com> Yes, I too would like to know if this is solved. I had asked about this earlier when working on a nice way to keep the scripts up-to-date for rebuilding everything. Regards, Randy >>> Dragi?a Duri* 2/26/2008 5:00 AM >>> I am trying to figure out systematic way to map dependicies of packages so I can make nice hierarchy for RPM building... It's not too hard to map it out from m3makefiles, but it will be much better if someone already solved it :). Is there such a map already out there? TIA, dd -- Dragi?a Duri* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:10:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:10:30 -0500 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: <3AC8BC28-2E71-4E46-8E4C-5E17266721E2@cs.purdue.edu> The constants MOne, etc are used explicitly with specific precision by the compiler front-end. These constants indicate that they have a certain number of significant bytes in their representation. If you truncate the 8 bytes to 4 bytes for 32-bit then we know that the value will still be correct. Making it length 1 breaks the use of the contants in both 32-bit and 64-bit representations. These changes were made when I put in the LONGINT support -- that's why they are different from PM3. On Feb 26, 2008, at 2:53 PM, Jay wrote: > I haven't tested this but it looks very suspicious.. > When targeting 64 bit targets, the compiler thinks [-1 .. 1] is > empty. > When compiling things like "compare" functions. > I didn't debug it but just looked at the code. > > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v > retrieving revision 1.4 > diff -r1.4 TInt.i3 > 26c26 > < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; > --- > > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff, > 16_ff,16_ff,16_ff,16_ff}}; > > > another fix might be: > > > > MOne = Int{1, IBytes{16_ff}}; > > IBytes used to be 16 bit integers but now is 8 bit integers. > PM3 has: > > Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; > One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; > MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; > > which seems adequate for what is likely going on in these parts. > > I believe ".." fills with zeros, not the previous value. > > Also, is this objectionable? > > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v > retrieving revision 1.2 > diff -r1.2 TextLiteral.i3 > 15c15 > < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; > --- > > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - > 32; *) > > Maybe. The 32 bit compiler doesn't like such large types (that > follow from the use of this). > Maybe preferable to allow 32 bit hosted compiler to allow 64 bit > sized types? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Tue, 26 Feb 2008 18:53:58 +0000 > Subject: [M3devel] tangential 64 bit... > > alpha/osf doesn't work because basictypes/ctypes has a problem with > the 32bit or 64bit types. > specifically "unsigned long" is "empty" for some reason and many > errors cascade from that. > > if you change: > unsigned_int = [16_0 .. 16_ffffffff]; > to > unsigned_int = [16_0 .. 16_fffffffe]; > > you get: > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/TWord.m3", line 199 > *** > > Presumably fixing this first problem is the first step in any "real" > 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem > should just be fixed as a matter of course. > > I know this is the least of anyone's concerns.. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:14:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:14:37 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: <1C38F3E3-1E39-459D-879D-118C9D871E55@cs.purdue.edu> Legal depends on context, as you note. If you are able to see the representation of a given text then you can mess with it accordingly. The pointers for these are not to readonly memory. Note that you probably will break things if you try to write to TextLiteral.T.buf, since that might be readonly. Here be dragons, but my point was that every text has an underlying representation that may or may not be sensibly mutable. I am a strong believer in TEXT being immutable in the general case. On Feb 26, 2008, at 3:35 PM, Jay wrote: > Is that legal or is that subverting things? > It depends on the context? > Can the pointers be to read only memory in the code? > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: mika at async.caltech.edu > > Date: Tue, 26 Feb 2008 15:16:47 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] text inefficiency? good mutable string > type? arrays? > > > > ARRAY OF CHAR/WIDECHAR? > > > > These are available in the various Text implementations. For exampe, > > Text8.T.contents. One can freely mutate these at leisure and the > > higher-level text will appear to change! > > > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > > > > > Olaf Wagner writes: > > >> Quoting Jay : > > >> > > >>> I know this area has been brewing under the surface a while. > > >>> I'll bring it up. :) > > >>> > > >>> I assume texts are read only? > > >> > > >> Yes. > > >> > > >>> I know lots of systems have read only strings. > > >>> There are pluses and minus to them. They can be single- > instanced. > > >>> Some systems with read only strings have another type, such as > > >>> "StringBuilder" or "StringBuffer". > > >>> So -- I don't have a specific question, but maybe a mutable > string > > >>> "class" aka "type" is needed?Not necessarily in the language > but in > > >>> m3core or libm3? > > >>> Maybe it's already there? > > > > > > CharSeq.T? > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:18:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:18:24 -0500 Subject: [M3devel] volume of cm3-related email traffic In-Reply-To: <47C437CE.1E75.00D7.1@scires.com> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> <47C437CE.1E75.00D7.1@scires.com> Message-ID: Sounds like good practice to me! [Note that I am replying only to m3devel. :-) ] On Feb 26, 2008, at 4:01 PM, Randy Coleburn wrote: > I appreciate all the work everyone is doing these days on cm3, but I > am having a problem I'd like to describe. > I'm getting a large number of cm3-related email messages relayed to > me each day. In many cases, I'm getting two copies of each message > because folks are also addressing the message to me in addition to > the m3devel list. > > The email address I've put on the m3devel and m3commit lists is my > work email address. So, the large number of messages is now > interfering with my job. In the past, this wasn't a problem because > there weren't very many messages. > > I know I could change my email address for these mail lists to a > private home mailbox, but I would not be able to check this box as > frequently. Before I take this action, here are some suggestions I > have: > > 1. Don't include the original sender on your reply; instead, just > address to m3devel > [I know I've been guilty about just lazily hitting the reply button > without deleting the extra addresses, so this suggestion applies to > me as well.] > > 2. Try not to use m3devel as a blog for a steady-stream of > thought. Maybe we should setup a blog or something for this type of > activity. > > 3. Try to think through and test your changes throughly to cut down > on the number of commits. > > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:43:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:43:17 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> I suppose the question here is how often you exceed the 256-character stack-allocated buffer size? If not often then occasionally allocating in the heap is not a huge problem. I'm not too fussed about this anyway because generational GC will quickly reclaim things that die as young as this buffer does. I think you underestimate the effectiveness of modern GC algorithms. Anyway, optimizing here for short nm texts presumably handles the common case. Why work hard to optimize the uncommon case? On Feb 25, 2008, at 10:38 AM, Jay wrote: > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > Here is some apparently typical code: > > PROCEDURE Escape (nm: TEXT): TEXT = > VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (nm = NIL) THEN RETURN NIL; END; > len := Text.Length (nm); > IF (len + len <= NUMBER (buf)) > THEN RETURN DoEscape (nm, len, buf); > ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + > len)^); > END; > END Escape; > > PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF > CHAR): TEXT = > VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; > BEGIN > Text.SetChars (buf, nm); > FOR i := 0 TO len-1 DO > IF (buf[i] = BackSlash) THEN INC (n_escapes); END; > END; > IF (n_escapes = 0) THEN RETURN nm; END; > src := len - 1; > dest := src + n_escapes; > WHILE (src > 0) DO > c := buf[src]; DEC (src); > buf[dest] := c; DEC (dest); > IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); > END; > END; > RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); > END DoEscape; > > > Look at how inefficient this is. > For a long string it makes a heap allocation, even if in the end it > makes no changes to the string. > For any length string it copies it out to an array. > Then if there are any changes, it copies it again, probably into > heap, likely the input immediately becoming garbage. > Heap allocation may be fast, but building up garbage and causing > more work for the garbage collector I assume is bad. > And if the string had no backslashes, it's all a big waste. > > I assume texts are read only? > > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > > > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed? > Not necessarily in the language but in m3core or libm3? > Maybe it's already there? > > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a > good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => > wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not > characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Feb 27 00:14:31 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 26 Feb 2008 17:14:31 -0600 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: <47C49D57.4090600@wichita.edu> Mutating the Text implementations certainly could subvert the expected semantics of TEXT, for other TEXT values you might not expect to have any relation to what you are doing. But in my view, the much more important point is that ARRAY OF CHAR/ WIDECHAR, where you create your own values, are the mutable strings in Modula-3. You can pretty much do anything you want with this, including writing your own string abstraction, with different internal representation. In fact, I have done so, highly tailored to an application with specific, known performance characteristics and usage patterns. Jay wrote: > Is that legal or is that subverting things? > It depends on the context? > Can the pointers be to read only memory in the code? > > - Jay > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > To: mika at async.caltech.edu > > Date: Tue, 26 Feb 2008 15:16:47 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] text inefficiency? good mutable string type? > arrays? > > > > ARRAY OF CHAR/WIDECHAR? > > > > These are available in the various Text implementations. For exampe, > > Text8.T.contents. One can freely mutate these at leisure and the > > higher-level text will appear to change! > > > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > > > > > Olaf Wagner writes: > > >> Quoting Jay : > > >> > > >>> I know this area has been brewing under the surface a while. > > >>> I'll bring it up. :) > > >>> > > >>> I assume texts are read only? > > >> > > >> Yes. > > >> > > >>> I know lots of systems have read only strings. > > >>> There are pluses and minus to them. They can be single-instanced. > > >>> Some systems with read only strings have another type, such as > > >>> "StringBuilder" or "StringBuffer". > > >>> So -- I don't have a specific question, but maybe a mutable string > > >>> "class" aka "type" is needed?Not necessarily in the language but in > > >>> m3core or libm3? > > >>> Maybe it's already there? > > > > > > CharSeq.T? > > > > > ------------------------------------------------------------------------ > Climb to the top of the charts! Play the word scramble challenge with > star power. Play now! > -- ------------------------------------------------------------- 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 Wed Feb 27 00:46:26 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 23:46:26 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> Message-ID: Tony, what about the need to copy? The inability to iterate through characters without a function call per character? I guess though, from what you pointed out, a read only direct pointer is viable. And that removes the 256 character stack usage -- which is a bit piggy as it is. So then..I guess the next step in some compromise here is that it should perhaps be viable to get a read only pointer to a string (maybe already the case), compute the required size of the new one (follows naturally), and then be able to split up allocation and filling in of a string, a function to allocate and get a direct pointer, then fill in your data, then "seal" the text making it read only. And I guess really you can just carefully use the "subversive" method here -- up to you to not pass the "unsealed" text off to anyone else until you are done writing to it. Then just to deal with the varying representation but as I was suggesting, maybe that can be forced somehow. Maybe creation can specify an encoding, or the "get buffer" function could -- though ideally there is just one, not two. The stack vs. heap behavior is also not ideal in that it's nice for the performance of something to scale linearly with input, not suddenly slow way down when data exceeds some arbitrary threshold. Granted, a lot of code just starts failing, so merely slowing down is "progress". As well, eventually you end up swapping to disk, if you don't first run out of address space, so there will be limits at which things slow down or fail, just that they ought to be fairly large. I also rather hoped/assumed that compile time text constants were formed constant-ly by the compiler, that the compiler knows their runtime layout. I realize the division of labor between compiler and runtime can be made at varying points, with varying resulting flexibility, but also varying resulting efficiency. - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 17:43:17 -0500Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays? I suppose the question here is how often you exceed the 256-character stack-allocated buffer size? If not often then occasionally allocating in the heap is not a huge problem. I'm not too fussed about this anyway because generational GC will quickly reclaim things that die as young as this buffer does. I think you underestimate the effectiveness of modern GC algorithms. Anyway, optimizing here for short nm texts presumably handles the common case. Why work hard to optimize the uncommon case? On Feb 25, 2008, at 10:38 AM, Jay wrote: I know this area has been brewing under the surface a while.I'll bring it up. :) Here is some apparently typical code: PROCEDURE Escape (nm: TEXT): TEXT = VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; BEGIN IF (nm = NIL) THEN RETURN NIL; END; len := Text.Length (nm); IF (len + len <= NUMBER (buf)) THEN RETURN DoEscape (nm, len, buf); ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + len)^); END; END Escape;PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF CHAR): TEXT = VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; BEGIN Text.SetChars (buf, nm); FOR i := 0 TO len-1 DO IF (buf[i] = BackSlash) THEN INC (n_escapes); END; END; IF (n_escapes = 0) THEN RETURN nm; END; src := len - 1; dest := src + n_escapes; WHILE (src > 0) DO c := buf[src]; DEC (src); buf[dest] := c; DEC (dest); IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); END; END; RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); END DoEscape;Look at how inefficient this is.For a long string it makes a heap allocation, even if in the end it makes no changes to the string.For any length string it copies it out to an array.Then if there are any changes, it copies it again, probably into heap, likely the input immediately becoming garbage.Heap allocation may be fast, but building up garbage and causing more work for the garbage collector I assume is bad.And if the string had no backslashes, it's all a big waste. I assume texts are read only? I know lots of systems have read only strings.There are pluses and minus to them. They can be single-instanced.Some systems with read only strings have another type, such as "StringBuilder" or "StringBuffer".So -- I don't have a specific question, but maybe a mutable string "class" aka "type" is needed?Not necessarily in the language but in m3core or libm3?Maybe it's already there? I just spent a few hours diddling with arrays of chars.Unfortunately they are not resizable.It was not entirely satisfactory. Besides the array I had to pass around a length and a start.Wrapping this up in one record TYPE MutableString= ... might be a good idea. For more efficient read only access, would it be reasonable for the runtime to materialize on-demand 8 bit and 16 bit representations of a string if a user calls some new thing like Text.GetDirectA (t: TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF WIDECHAR? Throw an exception if the string cannot be represented with 8 bit characters? Or use utf8? Besides, I know I'm a big predictable whiner but I like how this works in Windows..It may not have been as seamless, but it works and it really doesn't tend to break or slow down existing code.roughly: "foo" is an 8 bit string of type char* (or const char* or possibly const char[4]) L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) "L" for "long" aka "wide" Functions must be written to specifically use one or the other.In C++ you can templatize. There is std::string and std::wstring that are template instantiations.Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc.And really there's no point in 8 bit strings.If you have a blob, that's an array of bytes or something, not characters. It works. Utf8 is another seemingly popular route but I think it's a hack.I think mostly people don't touch their code and say, voila, it's utf8, and they only really support the same old English or possibly 8 bit characters (some European characters).Granted, to some extent, this does work, as long as you don't do anything with the string but strlen, strcpy, and some others and pass it to code that does treat it correctly. Still, variably sized encodings seem like a bad idea here, and 16 bits per character seem affordable enough. And yes, I know that Unicode is actually know 20 bits per character and some characters take two wchar_ts but I try to ignore that...And I know there is a lot of existing code, but sometimes there is a need for progress too... Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 27 00:57:59 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 23:57:59 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <47C49D57.4090600@wichita.edu> References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> <47C49D57.4090600@wichita.edu> Message-ID: Right that arrays of chars/widechars make good strings, however you run into the problem of what is the ubiquitous type that is good to have around because any other code can deal with it. It's often nice to have fewer types and therefore more easier interoperability among code -- avoid any thick translation layer or conversion of data back and forth. It's tough though of course, since not one size (type) fits all. It seems annoying and wasteful, but also plain ok, for everyone to have their own string, array, list, etc. types. My "crazy" view though is that it is better to have one string class per programmer than any programmer with no string type to use. Fewer types/libraries would be preferable, but the alternative of anyone having none is worse. It is easy enough to write these things for yourself if there really is no acceptable existing option. (though the ease with which folks dismiss existing alternatives is also bad) Some people claim they need to leave the writing of string/array/list to the super-skilled library developers, but I don't think so. The line between library producer and library consumer is not always so clear. I may not be capable of whipping together a windowing system or a threading library or compiler, but string and growable array are plenty easy enough. :) Sometimes the library writers aren't even so good.. I remember reading, if I interpreted it correctly, how the Python developers were so proud of their growable arrays that are so efficient because they grow in chunks of constant size larger than 1...except that's not actually how you write an efficient growable array, you have to grow exponentially -- by a factor greater than 1, such as 2 or 3 or 1.5. This is for the scenario of folks adding one element at a time. I also found Modula-3 arrays to be a little disappointing so far. Could be me at this point. I'd like to be able to change their length and possibly remove elements from the start without a copy. I suppose that involves a dreaded "interior pointer" and gc problems. I know SOME about SUBARRAYS but so far, it seems SUBARRAY can only be passed as parameters or use in "surprisingly powerful" assignment: subarray(a, offset, length) := subarray(b, offset, length). It seems I cannot assign, like, a subarray to a reference. a: array [0..9] of integer, b : ref array [8..9] of integer := subarray(a, 8) ? I'll have to look into that too.. Really I was going to try to shut up today at Randy's request but folks responded.. :) - Jay > Date: Tue, 26 Feb 2008 17:14:31 -0600> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays?> > Mutating the Text implementations certainly could subvert the expected> semantics of TEXT, for other TEXT values you might not expect to have> any relation to what you are doing.> > But in my view, the much more important point is that ARRAY OF CHAR/> WIDECHAR, where you create your own values, are the mutable strings> in Modula-3. You can pretty much do anything you want with this,> including writing your own string abstraction, with different internal> representation. In fact, I have done so, highly tailored to an> application with specific, known performance characteristics and> usage patterns.> > Jay wrote:> > Is that legal or is that subverting things?> > It depends on the context?> > Can the pointers be to read only memory in the code?> > > > - Jay> > > > > > ------------------------------------------------------------------------> > > > > From: hosking at cs.purdue.edu> > > To: mika at async.caltech.edu> > > Date: Tue, 26 Feb 2008 15:16:47 -0500> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] text inefficiency? good mutable string type? > > arrays?> > >> > > ARRAY OF CHAR/WIDECHAR?> > >> > > These are available in the various Text implementations. For exampe,> > > Text8.T.contents. One can freely mutate these at leisure and the> > > higher-level text will appear to change!> > >> > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote:> > >> > > > Olaf Wagner writes:> > > >> Quoting Jay :> > > >>> > > >>> I know this area has been brewing under the surface a while.> > > >>> I'll bring it up. :)> > > >>>> > > >>> I assume texts are read only?> > > >>> > > >> Yes.> > > >>> > > >>> I know lots of systems have read only strings.> > > >>> There are pluses and minus to them. They can be single-instanced.> > > >>> Some systems with read only strings have another type, such as> > > >>> "StringBuilder" or "StringBuffer".> > > >>> So -- I don't have a specific question, but maybe a mutable string> > > >>> "class" aka "type" is needed?Not necessarily in the language but in> > > >>> m3core or libm3?> > > >>> Maybe it's already there?> > > >> > > > CharSeq.T?> > >> > > > > > ------------------------------------------------------------------------> > Climb to the top of the charts! Play the word scramble challenge with > > star power. Play now! > > > > -- > -------------------------------------------------------------> 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 _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Feb 27 10:41:10 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 Feb 2008 10:41:10 +0100 Subject: [M3devel] bootstrap from IL code? Message-ID: <1204105270.13580.10.camel@hias.m3w.org> If I remember correctly (fog of advanced age and all:), we used to have bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did not depend on installed Modula-3 compiler. Are there some scripts to make such bootstrap archive now? So we can make self-buildable package without Modula-3 compiler packaged in. dd -- Dragi?a Duri? From dragisha at m3w.org Wed Feb 27 10:57:35 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 Feb 2008 10:57:35 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204105270.13580.10.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> Message-ID: <1204106255.13580.13.camel@hias.m3w.org> I see where it is... But, somebody probably already did it... Is there short script or howto on making cm3-min substitute based on IL? And why we don't have cm3-min-*-*... buildable with only gcc on-system?? IMO, this would help anybody building system. dd On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote: > If I remember correctly (fog of advanced age and all:), we used to have > bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did > not depend on installed Modula-3 compiler. > > Are there some scripts to make such bootstrap archive now? So we can > make self-buildable package without Modula-3 compiler packaged in. > > dd > -- Dragi?a Duri? From wagner at elegosoft.com Wed Feb 27 11:35:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 11:35:03 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204106255.13580.13.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> Message-ID: <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Quoting Dragi?a Duri? : > I see where it is... But, somebody probably already did it... Is there > short script or howto on making cm3-min substitute based on IL? > > And why we don't have cm3-min-*-*... buildable with only gcc on-system?? > IMO, this would help anybody building system. This was in PM3, but has never been integrated into CM3. If you'd like to work on it, it will be great. We could even come to the point were we build distributions for most targets on one platforms (possibly with the exception of crossing 32->64 bit boundaries). When extending the existing scripts, please make sure that the existing interfaces and functions keep working. Olaf > dd > > On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote: >> If I remember correctly (fog of advanced age and all:), we used to have >> bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did >> not depend on installed Modula-3 compiler. >> >> Are there some scripts to make such bootstrap archive now? So we can >> make self-buildable package without Modula-3 compiler packaged in. >> >> dd -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 27 11:54:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 10:54:41 +0000 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Message-ID: DEC M3.6 was distributed as assembly and some C files. It could just as well be .obj files. Most of the C was the implementation of quake, but maybe also dtoa.c, hand.c, and such. There is already a lot here, there is something like having the build stop either right before running as or right before ld, and then somehow resuming after all the files are copied to the target. I thought Olaf would answer "more positively", and I thought the stuff in scripts/* does about what you want, and I believe there is good documentation on exactly this. I realize that in what I said there, there's a mystery as to how to "resume" on the target. Cm3 could about some big .sh or .cmd file easily enough. Maybe the difference is just the amount of "friendliness" of the process? Not easy enough for "beginners"? I really expect we'll, um, "cross" the 32/64 boundary relatively soon in terms of, um, cross building. Unless I'm badly mistaken as to the general design of cm3. It sure looks prepared to do correct compile time math how the target would. And heck, maybe it could just skip constant propagation if not? (gcc also uses a lib in to do correct floating point target math, one of the dependencies I was initially missing, ./configure complains clearly) Not sure, it might be matters of correctness and not just optimization that require target math. For array maximum sizes, if that was the only problem, probably reasonable to just have 32 bit limits (TextLiteral.i3 has a problem building because of this.) I need to try out NT386GNU's GUI stuff (X Windows), make sure all of "std" can build and run for some reasonably large set (a lot already builds), and fix the Windows bitmap problem, and maybe PPC_LINUX dynamic linking and get a current distribution out, but I think getting ALPHA_OSF to compile (but not assemble or link) is among the next good things to try, as a stepping stone to a "real" 64 bit target such as, as I said, AMD64, IA64, POWER64, SPARC64. AMD64 of course I think is the most interesting, the cheapest hardware and it runs "everything" -- Windows, Linux, I think Solaris -- and in all cases "both" architectures even, via multi boot and always/sometimes "one boot". (I know this is true of Windows, I believe it is optional on Linux depending on distribution/configuration, they call it "biarch", and unsure about Solaris, not sure it has an AMD64 port or not, but certainly it has x86.) IF IF IF I'm right as to how the compiler works, this really shouldn't be a big deal.. We'll see.. - Jay > Date: Wed, 27 Feb 2008 11:35:03 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] bootstrap from IL code?> > Quoting Dragi?a Duri? :> > > I see where it is... But, somebody probably already did it... Is there> > short script or howto on making cm3-min substitute based on IL?> >> > And why we don't have cm3-min-*-*... buildable with only gcc on-system??> > IMO, this would help anybody building system.> > This was in PM3, but has never been integrated into CM3. If you'd> like to work on it, it will be great. We could even come to the point> were we build distributions for most targets on one platforms (possibly> with the exception of crossing 32->64 bit boundaries).> > When extending the existing scripts, please make sure that the existing> interfaces and functions keep working.> > Olaf> > > dd> >> > On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote:> >> If I remember correctly (fog of advanced age and all:), we used to have> >> bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did> >> not depend on installed Modula-3 compiler.> >>> >> Are there some scripts to make such bootstrap archive now? So we can> >> make self-buildable package without Modula-3 compiler packaged in.> >>> >> dd> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 27 14:43:12 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 14:43:12 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204112891.13580.27.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> Message-ID: <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Wed, 2008-02-27 at 11:35 +0100, Olaf Wagner wrote: >> Quoting Dragi?a Duri? : >> >> > I see where it is... But, somebody probably already did it... Is there >> > short script or howto on making cm3-min substitute based on IL? >> > >> > And why we don't have cm3-min-*-*... buildable with only gcc on-system?? >> > IMO, this would help anybody building system. >> >> This was in PM3, but has never been integrated into CM3. If you'd >> like to work on it, it will be great. We could even come to the point >> were we build distributions for most targets on one platforms (possibly >> with the exception of crossing 32->64 bit boundaries). > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had problems > cross compiling on 32bit for 64bit... I've made some quick&dirty fix so > it was IL code being archived/transferred/compiled, and not assembly as > was usual at time... John Polstra extended and integrated that trick > into building system of PM3, I don't know where that code is now. > Anybody? It should be in the PM3 repository, which is hosted and available at the elego WWW servers, too: http://modula3.elegosoft.com/pm3/ There hasn't been much activity in recent years though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Feb 27 15:41:02 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 27 Feb 2008 09:41:02 -0500 Subject: [M3devel] bootstrap from IL code? In-Reply-To: References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Message-ID: Take a look at the code in pm3/language/modula3/m3compiler/ m3bootstrap: this would build a bunch of assembler files and a Makefile for bootstrapping without the M3 compiler. On Feb 27, 2008, at 5:54 AM, Jay wrote: > DEC M3.6 was distributed as assembly and some C files. It could just > as well be .obj files. > Most of the C was the implementation of quake, but maybe also > dtoa.c, hand.c, and such. > There is already a lot here, there is something like having the > build stop either right before running as or right before ld, and > then somehow resuming after all the files are copied to the target. > I thought Olaf would answer "more positively", and I thought the > stuff in scripts/* does about what you want, and I believe there is > good documentation on exactly this. I realize that in what I said > there, there's a mystery as to how to "resume" on the target. Cm3 > could about some big .sh or .cmd file easily enough. > Maybe the difference is just the amount of "friendliness" of the > process? Not easy enough for "beginners"? > > > I really expect we'll, um, "cross" the 32/64 boundary relatively > soon in terms of, um, cross building. > Unless I'm badly mistaken as to the general design of cm3. > It sure looks prepared to do correct compile time math how the > target would -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 27 21:02:00 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 20:02:00 +0000 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Message-ID: > Date: Feb 2008 > Quoting Dragi?a Duri? : > > >> were we build distributions for most targets on one platforms (possibly > >> with the exception of crossing 32->64 bit boundaries). > > > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had problems > > cross compiling on 32bit for 64bit... I've made some quick&dirty fix so These problems have all been fixed in gcc by now, right? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your HotmailR-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 27 21:30:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 27 Feb 2008 15:30:26 -0500 Subject: [M3devel] bootstrap from IL code? In-Reply-To: References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Message-ID: <3F1B6366-DA7A-42A8-B8CB-545B76E6D9AE@cs.purdue.edu> Should be fixed, yes. On Feb 27, 2008, at 3:02 PM, Jay wrote: > > Date: Feb 2008 > > Quoting Dragi?a Duri? : > > > > >> were we build distributions for most targets on one platforms > (possibly > > >> with the exception of crossing 32->64 bit boundaries). > > > > > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had > problems > > > cross compiling on 32bit for 64bit... I've made some > quick&dirty fix so > > > These problems have all been fixed in gcc by now, right? > > > - Jay > > Need to know the score, the latest news, or you need your HotmailR- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 27 22:23:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 22:23:05 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: <47C440A7.1E75.00D7.1@scires.com> References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> Message-ID: <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Quoting Randy Coleburn : > Yes, I too would like to know if this is solved. > I had asked about this earlier when working on a nice way to keep the > scripts up-to-date for rebuilding everything. > Regards, > Randy Perhaps I misunderstood what you were asking for; I've checked-in a package dependency list in scripts/cm3-pkg-deps now. The actual package paths relative to ROOT can be found in scripts/PKGS. A list of all packages is kept in scripts/pkginfo.txt. Let's see if this is useful. I'll add the program to extract the dependencies soon. Olaf >>>> Dragi?a Duri* 2/26/2008 5:00 AM >>> > I am trying to figure out systematic way to map dependicies of > packages > so I can make nice hierarchy for RPM building... It's not too hard to > map it out from m3makefiles, but it will be much better if someone > already solved it :). Is there such a map already out there? > > TIA, > dd > -- > Dragi?a Duri* > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 27 22:32:22 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 21:32:22 +0000 Subject: [M3devel] CM3 package dependicies In-Reply-To: <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Message-ID: > A list of all packages is kept in scripts/pkginfo.txt. I also plan to make scripts/python and scripts/win use pkginfo.txt, esp. scripts/python. If anyone cares, please speak up. I would also like filtering to be driven by pkginfo.txt, however that seems of quite low importance, esp. in ratio to how obvious the design is (not entirely obvious, like if something really really simple will suffice or be too ambiguous). Also, Olaf, about two months ago I believe you said "std should be all". I hesitated. "Are you certain?" I kind of also think filtering needs a command line override. Maybe just that do-pkg should do no filtering? You know, I always set OMIT_GCC and I occasionally want to build m3cc. I do like how sh can set env vars on the command line for just that invocation, but I'm not willing to switch to sh just for that feature with all that I'd lose. Again, though, I've settled into the larger consensus that this stuff doesn't matter too much. :) - Jay > Date: Wed, 27 Feb 2008 22:23:05 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] CM3 package dependicies> > Quoting Randy Coleburn :> > > Yes, I too would like to know if this is solved.> > I had asked about this earlier when working on a nice way to keep the> > scripts up-to-date for rebuilding everything.> > Regards,> > Randy> > Perhaps I misunderstood what you were asking for; I've checked-in> a package dependency list in scripts/cm3-pkg-deps now. The actual> package paths relative to ROOT can be found in scripts/PKGS.> A list of all packages is kept in scripts/pkginfo.txt.> > Let's see if this is useful.> > I'll add the program to extract the dependencies soon.> > Olaf> > >>>> Dragi?a Duri* 2/26/2008 5:00 AM >>>> > I am trying to figure out systematic way to map dependicies of> > packages> > so I can make nice hierarchy for RPM building... It's not too hard to> > map it out from m3makefiles, but it will be much better if someone> > already solved it :). Is there such a map already out there?> >> > TIA,> > dd> > --> > Dragi?a Duri* > >> >> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 00:14:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 00:14:49 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Message-ID: <20080228001449.v1fpl1gwg0c8gwcg@mail.elegosoft.com> Quoting Jay : >> A list of all packages is kept in scripts/pkginfo.txt. > I also plan to make scripts/python and scripts/win use pkginfo.txt, > esp. scripts/python. > If anyone cares, please speak up. > I would also like filtering to be driven by pkginfo.txt, however > that seems of quite low importance, esp. in ratio to how obvious the > design is (not entirely obvious, like if something really really > simple will suffice or be too ambiguous). > > Also, Olaf, about two months ago I believe you said "std should be all". > I hesitated. "Are you certain?" Seems I was wrong there. When we first made the system run again, we thought of `std' to be the compilable and usable packages. Now all packages should at least compile. Perhaps we should drop it or define a more sensible set of `standard packages'? > I kind of also think filtering needs a command line override. > Maybe just that do-pkg should do no filtering? Sounds OK. Or add a -f option. > You know, I always set OMIT_GCC and I occasionally want to build m3cc. > I do like how sh can set env vars on the command line for just that > invocation, but I'm not willing to switch to sh just for that > feature with all that I'd lose. We'll get you around in the end. This is Unix. Resistance is futile :-) > Again, though, I've settled into the larger consensus that this > stuff doesn't matter too much. :) Right :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 28 09:31:32 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:31:32 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 09:44:11 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:44:11 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 09:59:47 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:59:47 +0000 Subject: [M3devel] FW: put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000 pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 10:25:45 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 09:25:45 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: Is it easy enough for the commit mails to contain links to view all of the diffs described?That's be super duper nice. I find browsing the cvsweb very inefficient. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:59:47 +0000 truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000 pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 10:33:15 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 10:33:15 +0100 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: <20080228103315.tkxlxp32144kgsk8@mail.elegosoft.com> Quoting Jay : > Is it easy enough for the commit mails to contain links to view all > of the diffs described?That's be super duper nice. I'd say that depends on somebody providing the appropriate patch for the CVS commit hook script on birch.elegosoft.com ;-) Olaf PS: You can view the diffs related to every commit via the tinderbox page in the `Guilty' column though. That's quite convenient. > I find browsing the cvsweb very inefficient. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 28 14:03:07 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 13:03:07 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: Done.On birch, time sh -c "./do-pkg.sh realclean libm3 && ./do-pkg.sh buildship libm3" seems go from about 35 seconds to about 15 seconds.Let me know what improvements people see? OMIT_GCC=yes do-cm3-std probably is the best test.alarmthreads platforms (PPC_LINUX), no change (still rebuilding actually). NT386GNU still seems just as slow. At some point I will try batching up the cm3cg and/or as calls. Maybe via a wrapper on Windows only that then just makes n Win32 CreateProcess calls instead of n Cygwin vforks. It might be nice to have Quake callouts for before_first_compile, after_last_compile, before_first_assemble, after_last_assemble, though this brings up that there should perhaps be begin_package/end_package, for cm3 to become a multi-package builder..and then, really, multi-threaded, so there'd have to be maybe extra state variables passed around, maybe. (and then Cygwin's waitpid not being threadsafe breaks this...) (For prototyping, before_first compile is implied, after_last_compile/assemble is implied by make_lib/skip_lib/link, so any queuing up could be flushed at that point. Goal here being not to reduce process creates, but cygwin processes created from cygwin processes. oh, and I just realized, cm3cg should probably mark all data as "no copy" when targeting Cygwin. That might help a bunch.) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Tue, 29 Jan 2008 08:08:38 -0500> To: mika at async.caltech.edu> > Indeed. We definitely need to fix this...> > > On Jan 29, 2008, at 5:45 AM, Mika Nystrom wrote:> > > Jay writes:> > ..> >> It is painfully noticable how much more slowly NT386GNU m3cc > >> builds than NT=> >> 386MINGNU m3cc, presumably due to the underlying slower bash/sed/ > >> make etc.> > ..> >> > are you sure it's not the Thread.Sleep(0.1d0) in Process.Wait?> >> > Mika> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 14:28:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 14:28:55 +0100 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Quoting Jay : > Done.On birch, time sh -c "./do-pkg.sh realclean libm3 && > ./do-pkg.sh buildship libm3" > seems go from about 35 seconds to about 15 seconds.Let me know what > improvements people see? > OMIT_GCC=yes do-cm3-std probably is the best test.alarmthreads > platforms (PPC_LINUX), no change (still rebuilding actually). That's great. I'll let you know this evening how it works for me. > NT386GNU still seems just as slow. IIRC, process creation (fork) was always really slow in Cygwin. You cannot expect to be better than the underlying platform :-/ > At some point I will try batching up the cm3cg and/or as calls. > Maybe via a wrapper on Windows only that then just makes n Win32 > CreateProcess calls instead of n Cygwin vforks. > It might be nice to have Quake callouts for before_first_compile, > after_last_compile, before_first_assemble, after_last_assemble, > though this brings up that there should perhaps be > begin_package/end_package, for cm3 to become a multi-package > builder..and then, really, multi-threaded, so there'd have to be > maybe extra state variables passed around, maybe. (and then Cygwin's > waitpid not being threadsafe breaks this...) What we really should do to speed things up on modern multi-core processors is to implement parallel compilation (both front-end and back-end) of sources. This should be possible now that we have native thread support in M3. It will probably need some design changes though; I haven't looked into it, though I often thought this was a missing feature. Olaf > (For prototyping, before_first compile is implied, > after_last_compile/assemble is implied by make_lib/skip_lib/link, so > any queuing up could be flushed at that point. Goal here being not > to reduce process creates, but cygwin processes created from cygwin > processes. oh, and I just realized, cm3cg should probably mark all > data as "no copy" when targeting Cygwin. That might help a bunch.) > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Feb 28 15:09:14 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 09:09:14 -0500 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> No, please don't do that!!!! I hate it when I get a huge file of diffs. The comment should be descriptive enough to let me know if I care about the diffs or not. As an emacs user it is trivial for me to browse diffs there if I *really* care. But e-mail is the *wrong* place for diffs!! On Feb 28, 2008, at 4:25 AM, Jay wrote: > Is it easy enough for the commit mails to contain links to view all > of the diffs described? > That's be super duper nice. > I find browsing the cvsweb very inefficient. > > - Jay > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: FW: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:59:47 +0000 > > truncated again! and possibly misformated.. > > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the privacy/size/same- > across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command line > option. I will always turn it on. :) > > - Jay > > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines or > does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number > yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 28 15:12:21 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 09:12:21 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: I'm not sure what you mean here... Please explain further... On Feb 28, 2008, at 8:03 AM, Jay wrote: > Done. > On birch, > time sh -c "./do-pkg.sh realclean libm3 && ./do-pkg.sh buildship > libm3" > > seems go from about 35 seconds to about 15 seconds. > Let me know what improvements people see? > OMIT_GCC=yes do-cm3-std probably is the best test. > alarmthreads platforms (PPC_LINUX), no change (still rebuilding > actually). > > NT386GNU still seems just as slow. > At some point I will try batching up the cm3cg and/or as calls. > Maybe via a wrapper on Windows only that then just makes n Win32 > CreateProcess calls instead of n Cygwin vforks. > It might be nice to have Quake callouts for before_first_compile, > after_last_compile, before_first_assemble, after_last_assemble, > though this brings up that there should perhaps be begin_package/ > end_package, for cm3 to become a multi-package builder..and then, > really, multi-threaded, so there'd have to be maybe extra state > variables passed around, maybe. (and then Cygwin's waitpid not being > threadsafe breaks this...) > > (For prototyping, before_first compile is implied, > after_last_compile/assemble is implied by make_lib/skip_lib/link, so > any queuing up could be flushed at that point. Goal here being not > to reduce process creates, but cygwin processes created from cygwin > processes. oh, and I just realized, cm3cg should probably mark all > data as "no copy" when targeting Cygwin. That might help a bunch.) > > - Jay > > > > > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] nt386gnu threads? > > Date: Tue, 29 Jan 2008 08:08:38 -0500 > > To: mika at async.caltech.edu > > > > Indeed. We definitely need to fix this... > > > > > > On Jan 29, 2008, at 5:45 AM, Mika Nystrom wrote: > > > > > Jay writes: > > > .. > > >> It is painfully noticable how much more slowly NT386GNU m3cc > > >> builds than NT= > > >> 386MINGNU m3cc, presumably due to the underlying slower bash/sed/ > > >> make etc. > > > .. > > > > > > are you sure it's not the Thread.Sleep(0.1d0) in Process.Wait? > > > > > > Mika > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Feb 28 19:22:50 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 19:22:50 +0100 Subject: [M3devel] multiple pkg roots? Message-ID: <1204222970.13580.62.camel@hias.m3w.org> Is it possible to ship to more than one location, and/or have system find package imported in list of locations, instead from one location? dd -- Dragi?a Duri? From jayk123 at hotmail.com Thu Feb 28 19:47:45 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 18:47:45 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> References: <20080228082322.3662910D46B6@birch.elegosoft.com> <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> Message-ID: Links, not diffs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] put full paths to source files in debug infoDate: Thu, 28 Feb 2008 09:09:14 -0500 No, please don't do that!!!! I hate it when I get a huge file of diffs. The comment should be descriptive enough to let me know if I care about the diffs or not. As an emacs user it is trivial for me to browse diffs there if I *really* care. But e-mail is the *wrong* place for diffs!! On Feb 28, 2008, at 4:25 AM, Jay wrote: Is it easy enough for the commit mails to contain links to view all of the diffs described?That's be super duper nice.I find browsing the cvsweb very inefficient. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:59:47 +0000truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 19:49:25 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 18:49:25 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Message-ID: > You cannot expect to be better than the underlying platform :-/ Cygwin is much slower than the underying platform I believe.. - Jay [snip] _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Feb 28 20:05:34 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 13:05:34 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] Message-ID: <47C705FE.7090005@wichita.edu> I don't understand what the need for these paths is. In every complete program, all the interfaces and all the modules must have unique simple names, otherwise code could not refer to them. With the filename matchup rules, this should make all the simple file names unique too. So any debug commands should never need a path. And using simple names avoids the problems of moving compiled code. Is it more output from the debugger you want? If so, this could no doubt be done by the debugger itself with the debug info as it was. It already contained one copy of the full path to the source file in each object file, though I don't know of a place the debugger uses this now. Yes, I know the filename/modulename rules don't actually apply for modules, but not following them is a bad practice. I've been around that block many times with Ada, and believe me, it's a nightmare. Furthermore, then you wouldn't be able to name things in the debugger as ModuleName.VarOrProcInModule, This construct does not exist in code but is very useful in debugging, especially when InterfaceName/ModuleName is not one-to-one, e.g. when a module exports >1 interface, etc. Jay wrote: > truncated again! and possibly misformated.. > > > > > ------------------------------------------------------------------------ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the > privacy/size/same-across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > ------------------------------------------------------------------------ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command > line option. I will always turn it on. :) > > - Jay > > ------------------------------------------------------------------------ > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines > or does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your Hotmail?-get > your "fix". Check it out. -- ------------------------------------------------------------- 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 dragisha at m3w.org Thu Feb 28 20:13:21 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 20:13:21 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? Message-ID: <1204226001.13580.64.camel@hias.m3w.org> I am probably missing it, and few of my last runs had some problems... So - what is current state of m3gdb on LINUXLIBC6? Working? Under fixing? TIA, dd -- Dragi?a Duri? From hosking at cs.purdue.edu Thu Feb 28 20:13:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 14:13:48 -0500 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> Message-ID: <4CD621A0-B1CA-4B2B-8C79-5B7CFD577186@cs.purdue.edu> Sorry, read your message too quickly. Yes, links might be nice.... :-) On Feb 28, 2008, at 1:47 PM, Jay wrote: > Links, not diffs. > > - Jay > > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] put full paths to source files in debug info > Date: Thu, 28 Feb 2008 09:09:14 -0500 > > No, please don't do that!!!! I hate it when I get a huge file of > diffs. The comment should be descriptive enough to let me know if I > care about the diffs or not. As an emacs user it is trivial for me > to browse diffs there if I *really* care. But e-mail is the *wrong* > place for diffs!! > > On Feb 28, 2008, at 4:25 AM, Jay wrote: > > Is it easy enough for the commit mails to contain links to view all > of the diffs described? > That's be super duper nice. > I find browsing the cvsweb very inefficient. > > - Jay > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: FW: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:59:47 +0000 > > truncated again! and possibly misformated.. > > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the privacy/size/same- > across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command line > option. I will always turn it on. :) > > - Jay > > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines or > does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number > yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 28 20:12:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 14:12:33 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <47C705FE.7090005@wichita.edu> References: <47C705FE.7090005@wichita.edu> Message-ID: <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> I concur with Rodney on this. There are deeper issues here than simply avoiding the need to use dir in gdb. On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > I don't understand what the need for these paths is. In every > complete > program, all the interfaces and all the modules must have unique > simple > names, otherwise code could not refer to them. With the filename > matchup > rules, this should make all the simple file names unique too. So any > debug commands should never need a path. And using simple names > avoids > the problems of moving compiled code. > > Is it more output from the debugger you want? If so, this could no > doubt > be done by the debugger itself with the debug info as it was. It > already > contained one copy of the full path to the source file in each > object file, > though I don't know of a place the debugger uses this now. > > Yes, I know the filename/modulename rules don't actually apply for > modules, > but not following them is a bad practice. I've been around that > block many > times with Ada, and believe me, it's a nightmare. Furthermore, then > you > wouldn't be able to name things in the debugger as > ModuleName.VarOrProcInModule, > This construct does not exist in code but is very useful in > debugging, especially > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > exports >1 > interface, etc. > > Jay wrote: >> truncated again! and possibly misformated.. >> >> ------------------------------------------------------------------------ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: RE: put full paths to source files in debug info >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> pps: "webinfo" (Reactor?) and assertion failures are affected by >> this also, but not fully. >> Before you would have gotten: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "WaitProcessCygwin.m3", line 16 >> *** >> but now you get: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> *** >> I'd say the realpath call (or whatever the portable Modula-3 >> library >> call is) should be moved up to m3front to address these, and the >> parse.c change undone. >> As well, I believe resolving symlinks is happening too but >> that >> wasn't the point, so something instead of realpath might be >> preferable. Like, just see if the string starts ".\" or "..\", it >> will almost always start "..\", and if so, prepend current working >> directory and then workout the dots. >> It may also be reasonable to provide paths to the compiler >> to remove >> from the starts of paths, which would likely address the symlink >> issue, since they are more likely to be nearer the start of the >> path >> than the middle or end. As well as partly the >> privacy/size/same-across-machines issues. >> In any case, I think this easy small change is already very >> useful >> progress. Or does everyone else just fill up .gdbinit with dir >> commands? It seems to me that it shouldn't even that difficult, >> even >> if it isn't very difficult. >> Agreed? >> - Jay >> >> ------------------------------------------------------------------------ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: re: put full paths to source files in debug info >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> ps: does anyone care that binaries built from different cvs >> checkouts, but otherwise identical source, will no longer match, >> unless perhaps they are "stripped"? >> If so, or if any of the other issues bug people, or any other >> problem is brought up or discovered, this can be made a command >> line option. I will always turn it on. :) >> - Jay >> >> ------------------------------------------------------------------------ >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> > To: m3commit at elegosoft.com >> > From: jkrell at elego.de >> > Subject: [M3commit] CVS Update: cm3 >> > >> > CVSROOT: /usr/cvs >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> > >> > Modified files: >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> > Scanner.m3 >> > >> > Log message: >> > put full paths to source files in debug info >> > >> > This has the minor downsides of: >> > 1) grows the debug info (it is already huge; who is counting?) >> > 2) reveals file system layout in debug info (privacy?) >> > 3) does it inhibit debugging files from other people's machines >> or does gdb dir still work? >> > >> > but definitely makes for a more pleasant debugging experience >> when >> > debugging stuff you have built yourself. >> > >> > The linear searching to see if a name has been allocated a >> number yet >> > will obviously slow way down due to a large increase in common >> prefixes, >> > but that should be a hash table anyway. Linear search is lame. >> > (or a trie, but working from the ends of the strings, minus the >> last one or few >> > characters, due to common prefixes as well as common suffixes) >> > >> > Note that both m3front and m3cc changes are needed as m3front >> has >> paths >> > relative to the current working directory or such. >> > >> > For most packages, you can get by without the m3front change >> and >> just prepend >> > "../src/" to the path in m3cc, but that doesn't work for >> hierarchical packages >> > such as libm3 and m3core which I am debugging. >> ------------------------------------------------------------------------ >> Need to know the score, the latest news, or you need your Hotmail?- >> get your "fix". Check it out. > > > > -- > ------------------------------------------------------------- > 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 Feb 28 21:11:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 21:11:07 +0100 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Message-ID: <20080228211107.vkj5tlcs08c4csss@mail.elegosoft.com> Quoting Jay : >> You cannot expect to be better than the underlying platform :-/ > Cygwin is much slower than the underying platform I believe.. Thast's what I meant. You (CM3) cannot be better than Cygwin on NT386GNU. It's a problem of the Cygwin platform (not of CM3 and not of 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 wagner at elegosoft.com Thu Feb 28 21:18:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 21:18:36 +0100 Subject: [M3devel] multiple pkg roots? In-Reply-To: <1204222970.13580.62.camel@hias.m3w.org> References: <1204222970.13580.62.camel@hias.m3w.org> Message-ID: <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> Quoting Dragi?a Duri? : > Is it possible to ship to more than one location, and/or have system > find package imported in list of locations, instead from one location? This is currently only possible with overrides. CM3 does not support multiple package pools, though that would be a nice extension. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu Feb 28 21:42:13 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 21:42:13 +0100 Subject: [M3devel] multiple pkg roots? In-Reply-To: <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> References: <1204222970.13580.62.camel@hias.m3w.org> <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> Message-ID: <1204231333.13580.69.camel@hias.m3w.org> And, if overriden, then we cannot ship that package... I am looking at M3Build.m3 now... One of spaghetti pieces of cm3 :) dd On Thu, 2008-02-28 at 21:18 +0100, Olaf Wagner wrote: > Quoting Dragi?a Duri? : > > > Is it possible to ship to more than one location, and/or have system > > find package imported in list of locations, instead from one location? > > This is currently only possible with overrides. CM3 does not support > multiple package pools, though that would be a nice extension. > > Olaf -- Dragi?a Duri? From rodney.bates at wichita.edu Fri Feb 29 00:54:32 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 17:54:32 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204226001.13580.64.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> Message-ID: <47C749B8.1060906@wichita.edu> I have a long list of things to fix/improve in m3gdb, which I periodically work on. But it builds and runs for LINUXLIBC6 and does lots of useful thins. Just minutes ago, I happened to build it on a newly-installed Ubuntu, on LINUXLIBC6 and it is working as expected. For Ubuntu, I had to install package libncurses5-dev (apt-get install libncurses-dev) to get it to build. do-cm3-std.sh did not build it. I will check in my do-cm3-m3gdb.sh, which is a convenient way to build it. There is currently an annoying new bug in displaying subrange values in cm3-compiled code, that often incorrectly thinks the type's range is empty, and then complains the value is out of range. It does give you the numeric value anyway. I have added lots of new stuff to the expression evaluation in the past few years. You can type unmangled, qualified names of variables and procedures, execute procedure and method calls, etc. Much of this is summarized in the various checkin comments, which is, of course, not very handy as a way to read up. It has been on my list to write something up on this. As for other platforms, I don't have any around, and I'm not aware of anybody trying it. Dragi?a Duri? wrote: > I am probably missing it, and few of my last runs had some problems... > So - what is current state of m3gdb on LINUXLIBC6? Working? Under > fixing? > > TIA, > dd -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 01:25:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 18:25:36 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204226001.13580.64.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> Message-ID: <47C75100.9040004@wichita.edu> P.S. m3gdb dynamically detects and adapts to cm3 or pm3- compiled code (or src or ezm3). Also the integrated back end or the gcc-derived back ends. In cm3, code needs to be compiled with -gstabs+. Dragi?a Duri? wrote: > I am probably missing it, and few of my last runs had some problems... > So - what is current state of m3gdb on LINUXLIBC6? Working? Under > fixing? > > TIA, > dd -- ------------------------------------------------------------- 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 Fri Feb 29 01:19:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 Feb 2008 01:19:36 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C749B8.1060906@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> Message-ID: <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> Quoting "Rodney M. Bates" : > As for other platforms, I don't have any around, and I'm not aware of anybody > trying it. It compiles without problems on FreeBSD 6.3 and works as long as programs are linked with libthr.so (not with libpthread.so). I haven't used it much yet, and some things seemed to be strange; thread stack switching or viewing didn't work at all. If you want to try anything on FreeBSD, let me know, I can provide a remote login. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 29 02:01:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:01:02 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad? What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume. As is setting them by full name PosixProcess__WaitProcess. That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number. Do people do that? I guess the gui wrappers do, but I assume that'd still work. ? Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching? Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience. Gdb automatically shows me the source as I step, instead of just file name and line number. cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom: void assert_failed(const char* condition, const char* file, unsigned line); #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also: printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths. I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:36:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:36:08 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:35:25 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:35:25 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 04:01:42 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 22:01:42 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> On Feb 28, 2008, at 8:01 PM, Jay wrote: > Are you all serious? Telling the debugger the full path to source > files via the debuginfo is bad? > What are the issues? I want to know so that when I use the switch I > know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb > a few weeks ago). > > What I could imagine is affected is setting them by file and line > number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a > full path? Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not. > Gdb doesn't have any fuzzy matching? Not sure. > Maybe in gcc I can give multiple file names? Again, not sure. > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so > by default gdb was showing hardly anything at all, quite poor. I > admit, I'm at the start of the learning curve on gdb. I had to look > to find the dir command. I had to look to find display/x $pc. To use > the dir command, I have to constantly switch my slashes, since I get > the paths from dir /s/b. I use gdb under emacs... if the emacs bindings continue to work then OK, but if not then problems. > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned > line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. I look forward to Rodney's input since he has most experience with m3gdb and its expectations, and moreover with the current behavior of gdb for other languages. > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So > any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, > then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current > working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your > Hotmail?- > > >> get your "fix". Check it out. > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 04:02:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 22:02:23 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <4A155BD0-9DBF-4F25-96D5-C4AE16F61F62@cs.purdue.edu> Before we decide a switch is needed, can anyone tell me what gcc does by default for C? Does gcc have a switch already? On Feb 28, 2008, at 8:36 PM, Jay wrote: > If this must be a switch, what should the default be? > I suspect the default should be full paths. > > And then, should there be switches for each of: > debuginfo > assertions > webinfo > > "assertions" actually use the Modula-3 equivalent of __FILE__. > And so, what this should perhaps looks like is, using bogus Cish > names, > __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/ > unix/usomething.m3) > __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix > \fooposix.m3) > __LEAF_FILE__ (e.g. fooposix.m3) > > or maybe just the first two, and maybe the one that exists today > retains its meaning and a new "full file" is introduced. And then > folks can use it if they wish, and assertion maybe honors a switch. > > I hate to make everything TOO flexible and configurable though. It > can get confusing, and the underutilized options may get undertested > (but better now with increasing automated testing). > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; rodney.bates at wichita.edu > Date: Fri, 29 Feb 2008 01:01:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > Are you all serious? Telling the debugger the full path to source > files via the debuginfo is bad? > What are the issues? I want to know so that when I use the switch I > know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb > a few weeks ago). > > What I could imagine is affected is setting them by file and line > number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a > full path? > Gdb doesn't have any fuzzy matching? > Maybe in gcc I can give multiple file names? > > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so > by default gdb was showing hardly anything at all, quite poor. I > admit, I'm at the start of the learning curve on gdb. I had to look > to find the dir command. I had to look to find display/x $pc. To use > the dir command, I have to constantly switch my slashes, since I get > the paths from dir /s/b. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned > line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So > any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, > then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current > working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your > Hotmail?- > > >> get your "fix". Check it out. > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 04:52:50 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 03:52:50 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> Message-ID: > ...debugger itself with the debug info as it was. It already> > contained one copy of the full path to the source file in each > > object file, though I don't know of a place the debugger uses this now.btw, I don't think this part is true. I don't believe the object files contain full source paths anywhere. But oops, I admit I didn't open the .ms or .mo files and double check that. However, "the way it works", where "it" is the little bit of code I looked at, is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that path was passed in to gcc. My experience with gdb strongly suggests that this sort of path is the only one in the debug info. I will check more stuff tonight, the behavior of __FILE__, the behavior of gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the behavior of emacs+gdb (yet another learning curve..man, being low in the callstack requires familiarity with everyone's workflow above you..) I wonder as well if a list of directories can be put in the debug info. You know, partly as a size optimization, and possibly to address these issues. (of course the size optimization could be independently implemented) When I stepping, I don't really need gdb to show me the full path, that is often but not always noise, I just need it to know the full path so it can show the source. As things were, gdb wouldn't find source without dir commands. Command line debuggers are quite daunting. I don't know if it is worthwhile to strive to reduce the fear and pain they cause, or just suck it all up because you'll hardly make much of a dent anyway. ? - Jay CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to source files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500 On Feb 28, 2008, at 8:01 PM, Jay wrote: Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path? Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not. Gdb doesn't have any fuzzy matching? Not sure. Maybe in gcc I can give multiple file names? Again, not sure. This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I use gdb under emacs... if the emacs bindings continue to work then OK, but if not then problems. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. I look forward to Rodney's input since he has most experience with m3gdb and its expectations, and moreover with the current behavior of gdb for other languages. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Feb 29 10:39:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 29 Feb 2008 01:39:43 -0800 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: Your message of "Fri, 29 Feb 2008 03:52:50 GMT." Message-ID: <200802290939.m1T9dhnk058397@camembert.async.caltech.edu> I'm pretty sure I've seen full paths in ASSERT failures, using, perhaps, ezm3? It didn't cause any gdb problems (I use the old m3gdb a lot). Mika Jay writes: >--_93b0d79c-137f-47e2-9518-78e460fd7ea0_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> ...debugger itself with the debug info as it was. It already> > contained= > one copy of the full path to the source file in each > > object file, thou= >gh I don't know of a place the debugger uses this now.btw, I don't think th= >is part is true. >I don't believe the object files contain full source paths anywhere. >But oops, I admit I didn't open the .ms or .mo files and double check that. >However, "the way it works", where "it" is the little bit of code I looked = >at, >is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that >path was passed in to gcc. >=20 >My experience with gdb strongly suggests that this sort of path is the only >one in the debug info. >=20 >I will check more stuff tonight, the behavior of __FILE__, the behavior of = >gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the = >behavior of emacs+gdb (yet another learning curve..man, being low in the ca= >llstack requires familiarity with everyone's workflow above you..) >=20 >I wonder as well if a list of directories can be put in the debug info. >You know, partly as a size optimization, and possibly to address these issu= >es. > (of course the size optimization could be independently implemented) >When I stepping, I don't really need gdb to show me the full path, that is = >often but not always noise, I just need it to know the full path so it can = >show the source. As things were, gdb wouldn't find source without dir comma= >nds. >=20 >Command line debuggers are quite daunting. >I don't know if it is worthwhile to strive to reduce the fear and pain they= > cause, or just suck it all up because you'll hardly make much of a dent an= >yway. ? >=20 > - Jay > > >CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.= >eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to sour= >ce files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500 > > >On Feb 28, 2008, at 8:01 PM, Jay wrote: > > >Are you all serious? Telling the debugger the full path to source files via= > the debuginfo is bad?What are the issues? I want to know so that when I us= >e the switch I know what trouble I'm bringing myself. Setting breakpoints i= >n "modules", as .dll/.so files, is unaffected I presume.As is setting them = >by full name PosixProcess__WaitProcess.That is what I "always" do ("always"= > as in, I just started using gdb a few weeks ago). What I could imagine is = >affected is setting them by file and line number.Do people do that? I guess= > the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I = >should try out xcode and ddd and such? Do people say like break foo.c:#123?= > And now I've made them use a full path? > >Yes, I do this all the time...via the emacs keybindings -- not sure if full= > paths would break things or not. > >Gdb doesn't have any fuzzy matching? >Not sure. > > >Maybe in gcc I can give multiple file names? > >Again, not sure. > >This really greatly improves the out-of-the-box minimally configured debugg= >ing experience.Gdb automatically shows me the source as I step, instead of = >just file name and line number.cdb/windbg at least show disassembly by defa= >ult, but gdb doesn't, so by default gdb was showing hardly anything at all,= > quite poor. I admit, I'm at the start of the learning curve on gdb. I had = >to look to find the dir command. I had to look to find display/x $pc. To us= >e the dir command, I have to constantly switch my slashes, since I get the = >paths from dir /s/b. > >I use gdb under emacs... if the emacs bindings continue to work then OK, b= >ut if not then problems. > >I will make it a switch in cm3 and cm3cg if it is really a problem. In C it= > is a common idiom:void assert_failed(const char* condition, const char* fi= >le, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FI= >LE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the = >compiler on the command line", or "full path", depending on implementation.= > Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems li= >ke basic correctness to me, to give a debugger full paths.I'm quite surpris= >ed by the pushback. > >I look forward to Rodney's input since he has most experience with m3gdb an= >d its expectations, and moreover with the current behavior of gdb for other= > languages. > >Assertions I think should also be "fixed" further. And I suspect "webinfo" = >but that could wait until Reactor is available.. - Jay > >> From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 = >Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] = >FW: put full paths to source files in debug info]> > I concur with Rodney o= >n this. There are deeper issues here than > simply avoiding the need to use= > dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> >= > I don't understand what the need for these paths is. In every > > complete= >> > program, all the interfaces and all the modules must have unique > > si= >mple> > names, otherwise code could not refer to them. With the filename > = >> matchup> > rules, this should make all the simple file names unique too. = >So any> > debug commands should never need a path. And using simple names >= > > avoids> > the problems of moving compiled code.> >> > Is it more output = >from the debugger you want? If so, this could no > > doubt> > be done by th= >e debugger itself with the debug info as it was. It > > already> > containe= >d one copy of the full path to the source file in each > > object file,> > = >though I don't know of a place the debugger uses this now.> >> > Yes, I kno= >w the filename/modulename rules don't actually apply for > > modules,> > bu= >t not following them is a bad practice. I've been around that > > block man= >y> > times with Ada, and believe me, it's a nightmare. Furthermore, then > = >> you> > wouldn't be able to name things in the debugger as > > ModuleName.= >VarOrProcInModule,> > This construct does not exist in code but is very use= >ful in > > debugging, especially> > when InterfaceName/ModuleName is not on= >e-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wr= >ote:> >> truncated again! and possibly misformated..> >> > >> -------------= >-----------------------------------------------------------> >> From: jayk1= >23 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full path= >s to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> = >>> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> thi= >s also, but not fully.> >> Before you would have gotten:> >> ***> >> *** ru= >ntime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3"= >, line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *= >** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m= >3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable= > Modula-3 > >> library> >> call is) should be moved up to m3front to addres= >s these, and the> >> parse.c change undone.> >> As well, I believe resolvin= >g symlinks is happening too but > >> that> >> wasn't the point, so somethin= >g instead of realpath might be> >> preferable. Like, just see if the string= > starts ".\" or "..\", it> >> will almost always start "..\", and if so, pr= .. From rodney.bates at wichita.edu Fri Feb 29 17:43:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 10:43:35 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> Message-ID: <47C83637.6010602@wichita.edu> Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> As for other platforms, I don't have any around, and I'm not aware of >> anybody >> trying it. > > > It compiles without problems on FreeBSD 6.3 and works as long as > programs are linked with libthr.so (not with libpthread.so). Any more information on what the difference in these libraries is? > I haven't used it much yet, and some things seemed to be strange; > thread stack switching or viewing didn't work at all. m3gdb needs work on threads. I have never done anything on it. Unless Tony did some when he was working on it several years ago, I think it is pretty much as it came from SRC, and that was fairly primitive. Plus, the new pthreads implementation is not supported. Once I glanced at the code and it looked immediately like what was there would not work at all. This has been on my list a while. > > If you want to try anything on FreeBSD, let me know, I can provide > a remote login. Yes, that would be helpful. > > Olaf -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:11:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:11:35 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <47C83CC7.9060905@wichita.edu> Jay wrote: > Are you all serious? Telling the debugger the full path to source files > via the debuginfo is bad? Below. > What are the issues? I want to know so that when I use the switch I know > what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. In m3gdb, you can also say PosixProcess.WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb a > few weeks ago). > > What I could imagine is affected is setting them by file and line number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a full path? Yes. PosixProcess.m3:123 is the normal way. Since source file simple names are unique, this is enough in Modula-3. I suppose in C, if somebody actually had >1 source file with the same simple name, something messier would be needed, but normally, break Foo.c:123 is the way to do it. Likewise, before your change to debug info, output from (m3)gdb showing where something is stopped uses source file simple names and line numbers too. > Gdb doesn't have any fuzzy matching? > Maybe in gcc I can give multiple file names? > > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just file > name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so by > default gdb was showing hardly anything at all, quite poor. I admit, I'm > at the start of the learning curve on gdb. I had to look to find the dir > command. I had to look to find display/x $pc. To use the dir command, I > have to constantly switch my slashes, since I get the paths from dir /s/b. The paths to source are used in (m3)gdb only to display a portion of actual source code, not to identify file/line# places. For the former function only, (m3)gdb has to have full paths, and they must be as they may have changed since things were compiled/linked. I put -d command line options for all my source file paths (which do the same thing as dir gdb commands) in a startup file for any project that gets significant work. I do agree, it would be nice for a quick jump into a debugger, not to have to do this. It could only work, of course, if the source files are where they were at the time of compilation. The way to do this is for gdb to try the path from the object module, after normal use of dir/-d paths have failed. Since we can't change gdb, this would only be in m3gdb. On big advantage of this would be that it would work when one needs to debug right into the runtime system, as I do somewhat regularly. That requires several additional paths that one would not ordinarily have specified. The way we are installing Modula-3 now, it is a pretty safe bet that, if the source exists at all, then it where it was when the runtime system was compiled. (Well, copies of the interfaces do get placed in the install directory, but I'm not sure m3gdb ever displays non-executable code, which is all that interfaces have.) You have convinced me to add this to my list. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) > : (void)0) > We don't have anything like __FILE__ and __LINE__ in Modula-3. I have a largish program full of assertions with it's own coded assertion handling, including recoverable (in a sense, roll back to a consistent state) assertion failures. It could use something like this. But it also seems pretty hackish to me too. > __FILE__ can vary between "the parameter to the compiler on the command > line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a debugger > full paths. People can and often do move executables to different machines and also sometimes move source trees around on the original machine. Using simple file names within an executable (of which there is always exactly one) is invariant to all this, and a lot shorter to type/read. > I'm quite surprised by the pushback. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your Hotmail?- > > >> get your "fix". Check it out. > > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your Hotmail?-get > your "fix". Check it out. -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:18:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:18:15 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204267238.13580.75.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <1204267238.13580.75.camel@hias.m3w.org> Message-ID: <47C83E57.4060202@wichita.edu> Hmm. I'm not sure what happens here. It will be the same as the stock gdb (6.4) from which m3gdb is derived. I think it has a way of getting debug info from separate files, but I have never used this. The m3gdb changes to gdb don't do anything about this. I have, a few times, at intervals of two or three years, forward ported (back ported? what does one call this?) the Modula-3 changes into newer gdb releases. If there is something in the newest gdb that is really needed, I can do that again, although when I last thought about it (6.7), there was some target gdb had dropped that we still have in cm3. Dragi?a Duri? wrote: > During RPM building process, rpmbuild strips debug info and packs it > separatelly. Is m3gbd recognizing this situation and using debug info > in, for example: > > /usr/lib/debug/usr/local/cm3/bin/m3gdb.debug > /usr/lib/debug/usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/parseparams/LINUXLIBC6/libm3parseparams.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/set/LINUXLIBC6/libset.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/tcp/LINUXLIBC6/libm3tcp.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/tempfiles/LINUXLIBC6/libTempFiles.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/udp/LINUXLIBC6/libUDP.so.5.debug > > TIA, > dd > > On Thu, 2008-02-28 at 17:54 -0600, Rodney M. Bates wrote: > >>I have a long list of things to fix/improve in m3gdb, which I periodically >>work on. But it builds and runs for LINUXLIBC6 and does lots of useful thins. >> >>Just minutes ago, I happened to build it on a newly-installed Ubuntu, on >>LINUXLIBC6 and it is working as expected. For Ubuntu, I had to install >>package libncurses5-dev (apt-get install libncurses-dev) to get it to >>build. do-cm3-std.sh did not build it. I will check in my do-cm3-m3gdb.sh, >>which is a convenient way to build it. >> >>There is currently an annoying new bug in displaying subrange values in >>cm3-compiled code, that often incorrectly thinks the type's range is empty, >>and then complains the value is out of range. It does give you the numeric >>value anyway. >> >>I have added lots of new stuff to the expression evaluation in the past few >>years. You can type unmangled, qualified names of variables and procedures, >>execute procedure and method calls, etc. Much of this is summarized in the >>various checkin comments, which is, of course, not very handy as a way to >>read up. It has been on my list to write something up on this. >> >>As for other platforms, I don't have any around, and I'm not aware of anybody >>trying it. >> >>Dragi?a Duri? wrote: >> >>>I am probably missing it, and few of my last runs had some problems... >>>So - what is current state of m3gdb on LINUXLIBC6? Working? Under >>>fixing? >>> >>>TIA, >>>dd >> -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:32:49 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:32:49 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> Message-ID: <47C841C1.3090202@wichita.edu> Jay wrote: > > ...debugger itself with the debug info as it was. It already > > > contained one copy of the full path to the source file in each > > > object file, though I don't know of a place the debugger uses this now. > > btw, I don't think this part is true. > I don't believe the object files contain full source paths anywhere. > But oops, I admit I didn't open the .ms or .mo files and double check that. > However, "the way it works", where "it" is the little bit of code I > looked at, > is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that > path was passed in to gcc. > > My experience with gdb strongly suggests that this sort of path is the only > one in the debug info. Evidence: ----------------------------------------------------------------------------------------------- [rodney at selkirk LINUXLIBC6]$ objdump -G Sets.mo | more Sets.mo: file format elf32-i386 Contents of .stab section: Symnum n_type n_othr n_desc n_value n_strx String -1 HdrSym 0 839 00001db3 1 0 SO 0 0 00000000 9 /home/rodney/proj/util/m3/ordsets/LINUXLIBC6/ 1 SO 0 0 00000000 55 Sets.mc 2 OPT 0 0 00000000 63 gcc2_compiled. ... A bunch of irrelevant type definitions deleted ......... 3 LSYM 0 0 00000000 78 26 SOL 0 0 00000000 1353 Sets.m3 ----------------------------------------------------------------------------------------------- This is from an earlier compiler, before your change. Your change shows up in the last line, in front of Sets.m3. The path in the separate SO line is to the compiled object file, not the source. For Modula-3, getting the source file is usually trivial, although not always, especially the RTS. When changing m3gdb to use this after normal dir/-d paths have failed, I would consider changing cm3 to emit a 3rd SO line with the source path, *IF* this didn't choke stock gdb, which I doubt it would. However m3gdb works on code compiled by all the compilers, including older versions of cm3, so perhaps searching below ../src would be needed anyway. > > I will check more stuff tonight, the behavior of __FILE__, the behavior > of gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and > MAYBE the behavior of emacs+gdb (yet another learning curve..man, being > low in the callstack requires familiarity with everyone's workflow above > you..) > > I wonder as well if a list of directories can be put in the debug info. > You know, partly as a size optimization, and possibly to address these > issues. > (of course the size optimization could be independently implemented) > When I stepping, I don't really need gdb to show me the full path, that > is often but not always noise, I just need it to know the full path so > it can show the source. As things were, gdb wouldn't find source without > dir commands. > > Command line debuggers are quite daunting. > I don't know if it is worthwhile to strive to reduce the fear and pain > they cause, or just suck it all up because you'll hardly make much of a > dent anyway. ? > > - Jay > > ------------------------------------------------------------------------ > CC: rodney.bates at wichita.edu; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] FW: put full paths to source files in debug info] > Date: Thu, 28 Feb 2008 22:01:42 -0500 > > On Feb 28, 2008, at 8:01 PM, Jay wrote: > > Are you all serious? Telling the debugger the full path to > source files via the debuginfo is bad? > What are the issues? I want to know so that when I use the > switch I know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is > unaffected I presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using > gdb a few weeks ago). > > What I could imagine is affected is setting them by file and > line number. > Do people do that? I guess the gui wrappers do, but I assume > that'd still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use > a full path? > > > Yes, I do this all the time...via the emacs keybindings -- not sure > if full paths would break things or not. > > Gdb doesn't have any fuzzy matching? > > > Not sure. > > Maybe in gcc I can give multiple file names? > > > Again, not sure. > > This really greatly improves the out-of-the-box minimally > configured debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb > doesn't, so by default gdb was showing hardly anything at all, > quite poor. I admit, I'm at the start of the learning curve on > gdb. I had to look to find the dir command. I had to look to > find display/x $pc. To use the dir command, I have to constantly > switch my slashes, since I get the paths from dir /s/b. > > > I use gdb under emacs... if the emacs bindings continue to work > then OK, but if not then problems. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, > unsigned line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. > > > I look forward to Rodney's input since he has most experience with > m3gdb and its expectations, and moreover with the current behavior > of gdb for other languages. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > ------------------------------------------------------------------------ > >> From: hosking at cs.purdue.edu >> To: rodney.bates at wichita.edu >> Date: Thu, 28 Feb 2008 14:12:33 -0500 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: put full paths to source files in > debug info] >> >> I concur with Rodney on this. There are deeper issues here than >> simply avoiding the need to use dir in gdb. >> >> On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: >> >> > >> > I don't understand what the need for these paths is. In every >> > complete >> > program, all the interfaces and all the modules must have > unique >> > simple >> > names, otherwise code could not refer to them. With the > filename >> > matchup >> > rules, this should make all the simple file names unique > too. So any >> > debug commands should never need a path. And using simple names >> > avoids >> > the problems of moving compiled code. >> > >> > Is it more output from the debugger you want? If so, this > could no >> > doubt >> > be done by the debugger itself with the debug info as it > was. It >> > already >> > contained one copy of the full path to the source file in each >> > object file, >> > though I don't know of a place the debugger uses this now. >> > >> > Yes, I know the filename/modulename rules don't actually > apply for >> > modules, >> > but not following them is a bad practice. I've been around that >> > block many >> > times with Ada, and believe me, it's a nightmare. > Furthermore, then >> > you >> > wouldn't be able to name things in the debugger as >> > ModuleName.VarOrProcInModule, >> > This construct does not exist in code but is very useful in >> > debugging, especially >> > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module >> > exports >1 >> > interface, etc. >> > >> > Jay wrote: >> >> truncated again! and possibly misformated.. >> >> >> >> > ------------------------------------------------------------------------ >> >> From: jayk123 at hotmail.com >> >> To: m3devel at elegosoft.com >> >> Subject: RE: put full paths to source files in debug info >> >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> >> pps: "webinfo" (Reactor?) and assertion failures are > affected by >> >> this also, but not fully. >> >> Before you would have gotten: >> >> *** >> >> *** runtime error: >> >> *** <*ASSERT*> failed. >> >> *** file "WaitProcessCygwin.m3", line 16 >> >> *** >> >> but now you get: >> >> *** >> >> *** runtime error: >> >> *** <*ASSERT*> failed. >> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> >> *** >> >> I'd say the realpath call (or whatever the portable Modula-3 >> >> library >> >> call is) should be moved up to m3front to address these, > and the >> >> parse.c change undone. >> >> As well, I believe resolving symlinks is happening too but >> >> that >> >> wasn't the point, so something instead of realpath might be >> >> preferable. Like, just see if the string starts ".\" or > "..\", it >> >> will almost always start "..\", and if so, prepend current > working >> >> directory and then workout the dots. >> >> It may also be reasonable to provide paths to the compiler >> >> to remove >> >> from the starts of paths, which would likely address the > symlink >> >> issue, since they are more likely to be nearer the start of > the >> >> path >> >> than the middle or end. As well as partly the >> >> privacy/size/same-across-machines issues. >> >> In any case, I think this easy small change is already very >> >> useful >> >> progress. Or does everyone else just fill up .gdbinit with dir >> >> commands? It seems to me that it shouldn't even that > difficult, >> >> even >> >> if it isn't very difficult. >> >> Agreed? >> >> - Jay >> >> >> >> > ------------------------------------------------------------------------ >> >> From: jayk123 at hotmail.com >> >> To: m3devel at elegosoft.com >> >> Subject: re: put full paths to source files in debug info >> >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> >> ps: does anyone care that binaries built from different cvs >> >> checkouts, but otherwise identical source, will no longer > match, >> >> unless perhaps they are "stripped"? >> >> If so, or if any of the other issues bug people, or any other >> >> problem is brought up or discovered, this can be made a command >> >> line option. I will always turn it on. :) >> >> - Jay >> >> >> >> > ------------------------------------------------------------------------ >> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> >> > To: m3commit at elegosoft.com >> >> > From: jkrell at elego.de >> >> > Subject: [M3commit] CVS Update: cm3 >> >> > >> >> > CVSROOT: /usr/cvs >> >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> >> > >> >> > Modified files: >> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> >> > Scanner.m3 >> >> > >> >> > Log message: >> >> > put full paths to source files in debug info >> >> > >> >> > This has the minor downsides of: >> >> > 1) grows the debug info (it is already huge; who is > counting?) >> >> > 2) reveals file system layout in debug info (privacy?) >> >> > 3) does it inhibit debugging files from other people's > machines >> >> or does gdb dir still work? >> >> > >> >> > but definitely makes for a more pleasant debugging > experience >> >> when >> >> > debugging stuff you have built yourself. >> >> > >> >> > The linear searching to see if a name has been allocated a >> >> number yet >> >> > will obviously slow way down due to a large increase in > common >> >> prefixes, >> >> > but that should be a hash table anyway. Linear search is > lame. >> >> > (or a trie, but working from the ends of the strings, > minus the >> >> last one or few >> >> > characters, due to common prefixes as well as common > suffixes) >> >> > >> >> > Note that both m3front and m3cc changes are needed as > m3front >> >> has >> >> paths >> >> > relative to the current working directory or such. >> >> > >> >> > For most packages, you can get by without the m3front change >> >> and >> >> just prepend >> >> > "../src/" to the path in m3cc, but that doesn't work for >> >> hierarchical packages >> >> > such as libm3 and m3core which I am debugging. >> >> > ------------------------------------------------------------------------ >> >> Need to know the score, the latest news, or you need your > Hotmail?- >> >> get your "fix". Check it out. > > >> > >> > >> > -- >> > ------------------------------------------------------------- >> > 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 >> > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". Check it out. > > > > > ------------------------------------------------------------------------ > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > -- ------------------------------------------------------------- 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 dragisha at m3w.org Fri Feb 29 18:20:35 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 29 Feb 2008 18:20:35 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C83637.6010602@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> Message-ID: <1204305635.13580.82.camel@hias.m3w.org> On Fri, 2008-02-29 at 10:43 -0600, Rodney M. Bates wrote: > m3gdb needs work on threads. I have never done anything on it. > Unless Tony did some when he was working on it several years ago, > I think it is pretty much as it came from SRC, and that was fairly > primitive. Plus, the new pthreads implementation is not supported. > Once I glanced at the code and it looked immediately like what was > there would not work at all. This has been on my list a while. "Stock" gdb does support pthreads. Is that not enough for m3gdb? As for former M3 threads, msgdb had patches to go through thread lists, and many things more. As current implementation has no such kind of control over threads, I see no point in pursuing anything similar to what was before. > > > > > If you want to try anything on FreeBSD, let me know, I can provide > > a remote login. > > Yes, that would be helpful. > > > > > Olaf > -- Dragi?a Duri? From hosking at cs.purdue.edu Fri Feb 29 18:46:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 12:46:07 -0500 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C83637.6010602@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> Message-ID: m3gdb should probably avoid any specific reliance on the particular threads implementation. If using pthreads, then gdb already has support for that (I frequently debug threads issues for CM3 using the regular gdb without any problems). If using SIGVTALRM threads then I would suggest that users will need to be familiar with the thread scheduling points that it uses (triggered by SIGVTALRM, and implemented by Thread.Transfer). Since there is no way for m3gdb to "switch" contexts for SIGVTALRM threads then it really might as well be agnostic about threads generally. In summary, there should not be need for *special* support for threads in m3gdb. 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 Feb 29, 2008, at 11:43 AM, Rodney M. Bates wrote: > > > Olaf Wagner wrote: >> Quoting "Rodney M. Bates" : >>> As for other platforms, I don't have any around, and I'm not aware >>> of anybody >>> trying it. >> It compiles without problems on FreeBSD 6.3 and works as long as >> programs are linked with libthr.so (not with libpthread.so). > > Any more information on what the difference in these libraries is? > >> I haven't used it much yet, and some things seemed to be strange; >> thread stack switching or viewing didn't work at all. > > m3gdb needs work on threads. I have never done anything on it. > Unless Tony did some when he was working on it several years ago, > I think it is pretty much as it came from SRC, and that was fairly > primitive. Plus, the new pthreads implementation is not supported. > Once I glanced at the code and it looked immediately like what was > there would not work at all. This has been on my list a while. > >> If you want to try anything on FreeBSD, let me know, I can provide >> a remote login. > > Yes, that would be helpful. > >> Olaf > > -- > ------------------------------------------------------------- > 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 Fri Feb 29 18:46:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 12:46:49 -0500 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204305635.13580.82.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> Message-ID: <37E0E1B4-710C-4A1D-B42F-380E14451D5F@cs.purdue.edu> Precisely! 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 Feb 29, 2008, at 12:20 PM, Dragi?a Duri? wrote: > On Fri, 2008-02-29 at 10:43 -0600, Rodney M. Bates wrote: >> m3gdb needs work on threads. I have never done anything on it. >> Unless Tony did some when he was working on it several years ago, >> I think it is pretty much as it came from SRC, and that was fairly >> primitive. Plus, the new pthreads implementation is not supported. >> Once I glanced at the code and it looked immediately like what was >> there would not work at all. This has been on my list a while. > > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > > As for former M3 threads, msgdb had patches to go through thread > lists, and many things more. As current implementation has no such > kind > of control over threads, I see no point in pursuing anything similar > to > what was before. > >> >>> >>> If you want to try anything on FreeBSD, let me know, I can provide >>> a remote login. >> >> Yes, that would be helpful. >> >>> >>> Olaf >> > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 19:27:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 13:27:51 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <47C83CC7.9060905@wichita.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <47C83CC7.9060905@wichita.edu> Message-ID: On Feb 29, 2008, at 12:11 PM, Rodney M. Bates wrote: > > > Jay wrote: >> Are you all serious? Telling the debugger the full path to source >> files via the debuginfo is bad? > > Below. > >> What are the issues? I want to know so that when I use the switch I >> know what trouble I'm bringing myself. >> Setting breakpoints in "modules", as .dll/.so files, is unaffected >> I presume. >> As is setting them by full name PosixProcess__WaitProcess. > > In m3gdb, you can also say PosixProcess.WaitProcess. > >> That is what I "always" do ("always" as in, I just started using >> gdb a few weeks ago). >> What I could imagine is affected is setting them by file and line >> number. >> Do people do that? I guess the gui wrappers do, but I assume that'd >> still work. ? >> Maybe it depends. I should try out xcode and ddd and such? >> Do people say like break foo.c:#123? And now I've made them use a >> full path? > > Yes. PosixProcess.m3:123 is the normal way. Since source file > simple names > are unique, this is enough in Modula-3. I suppose in C, if somebody > actually > had >1 source file with the same simple name, something messier > would be > needed, but normally, break Foo.c:123 is the way to do it. > > Likewise, before your change to debug info, output from (m3)gdb > showing where > something is stopped uses source file simple names and line numbers > too. > >> Gdb doesn't have any fuzzy matching? >> Maybe in gcc I can give multiple file names? >> This really greatly improves the out-of-the-box minimally >> configured debugging experience. >> Gdb automatically shows me the source as I step, instead of just >> file name and line number. >> cdb/windbg at least show disassembly by default, but gdb doesn't, >> so by default gdb was showing hardly anything at all, quite poor. I >> admit, I'm at the start of the learning curve on gdb. I had to look >> to find the dir command. I had to look to find display/x $pc. To >> use the dir command, I have to constantly switch my slashes, since >> I get the paths from dir /s/b. > > The paths to source are used in (m3)gdb only to display a portion of > actual > source code, not to identify file/line# places. For the former > function only, > (m3)gdb has to have full paths, and they must be as they may have > changed since > things were compiled/linked. I put -d command line options for all my > source file paths (which do the same thing as dir gdb commands) in a > startup > file for any project that gets significant work. > > I do agree, it would be nice for a quick jump into a debugger, not > to have > to do this. It could only work, of course, if the source files are > where > they were at the time of compilation. The way to do this is for gdb > to > try the path from the object module, after normal use of dir/-d > paths have > failed. Since we can't change gdb, this would only be in m3gdb. Indeed! Given that cm3 compiles in one location and ships to another it is important that full paths *not* be used I suspect. That way, one can have users of installed packages debug against their source as necessary. > On big advantage of this would be that it would work when one needs to > debug right into the runtime system, as I do somewhat regularly. That > requires several additional paths that one would not ordinarily have > specified. The way we are installing Modula-3 now, it is a pretty > safe > bet that, if the source exists at all, then it where it was when the > runtime system was compiled. > > (Well, copies of the interfaces do get placed in the install > directory, but > I'm not sure m3gdb ever displays non-executable code, which is all > that interfaces have.) > > You have convinced me to add this to my list. > >> I will make it a switch in cm3 and cm3cg if it is really a problem. >> In C it is a common idiom: >> void assert_failed(const char* condition, const char* file, >> unsigned line); >> #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, >> __LINE__) : (void)0) >> > > We don't have anything like __FILE__ and __LINE__ in Modula-3. I > have a > largish program full of assertions with it's own coded assertion > handling, > including recoverable (in a sense, roll back to a consistent state) > assertion > failures. It could use something like this. But it also seems > pretty hackish > to me too. Sure we do: Compiler.ThisLine() Compiler.ThisFile() > > >> __FILE__ can vary between "the parameter to the compiler on the >> command line", or "full path", depending on implementation. >> Also: >> printf("foo is %d in %s\n", foo, __FILE__). >> This really just seems like basic correctness to me, to give a >> debugger full paths. > > People can and often do move executables to different machines and > also > sometimes move source trees around on the original machine. Using > simple > file names within an executable (of which there is always exactly one) > is invariant to all this, and a lot shorter to type/read. Agreed. > > >> I'm quite surprised by the pushback. >> Assertions I think should also be "fixed" further. And I suspect >> "webinfo" but that could wait until Reactor is available.. >> - Jay >> ------------------------------------------------------------------------ >> > From: hosking at cs.purdue.edu >> > To: rodney.bates at wichita.edu >> > Date: Thu, 28 Feb 2008 14:12:33 -0500 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] FW: put full paths to source files in >> debug info] >> > >> > I concur with Rodney on this. There are deeper issues here than >> > simply avoiding the need to use dir in gdb. >> > >> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: >> > >> > > >> > > I don't understand what the need for these paths is. In every >> > > complete >> > > program, all the interfaces and all the modules must have unique >> > > simple >> > > names, otherwise code could not refer to them. With the filename >> > > matchup >> > > rules, this should make all the simple file names unique too. >> So any >> > > debug commands should never need a path. And using simple names >> > > avoids >> > > the problems of moving compiled code. >> > > >> > > Is it more output from the debugger you want? If so, this could >> no >> > > doubt >> > > be done by the debugger itself with the debug info as it was. It >> > > already >> > > contained one copy of the full path to the source file in each >> > > object file, >> > > though I don't know of a place the debugger uses this now. >> > > >> > > Yes, I know the filename/modulename rules don't actually apply >> for >> > > modules, >> > > but not following them is a bad practice. I've been around that >> > > block many >> > > times with Ada, and believe me, it's a nightmare. Furthermore, >> then >> > > you >> > > wouldn't be able to name things in the debugger as >> > > ModuleName.VarOrProcInModule, >> > > This construct does not exist in code but is very useful in >> > > debugging, especially >> > > when InterfaceName/ModuleName is not one-to-one, e.g. when a >> module >> > > exports >1 >> > > interface, etc. >> > > >> > > Jay wrote: >> > >> truncated again! and possibly misformated.. >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> From: jayk123 at hotmail.com >> > >> To: m3devel at elegosoft.com >> > >> Subject: RE: put full paths to source files in debug info >> > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> > >> pps: "webinfo" (Reactor?) and assertion failures are affected by >> > >> this also, but not fully. >> > >> Before you would have gotten: >> > >> *** >> > >> *** runtime error: >> > >> *** <*ASSERT*> failed. >> > >> *** file "WaitProcessCygwin.m3", line 16 >> > >> *** >> > >> but now you get: >> > >> *** >> > >> *** runtime error: >> > >> *** <*ASSERT*> failed. >> > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> > >> *** >> > >> I'd say the realpath call (or whatever the portable Modula-3 >> > >> library >> > >> call is) should be moved up to m3front to address these, and the >> > >> parse.c change undone. >> > >> As well, I believe resolving symlinks is happening too but >> > >> that >> > >> wasn't the point, so something instead of realpath might be >> > >> preferable. Like, just see if the string starts ".\" or "..\", >> it >> > >> will almost always start "..\", and if so, prepend current >> working >> > >> directory and then workout the dots. >> > >> It may also be reasonable to provide paths to the compiler >> > >> to remove >> > >> from the starts of paths, which would likely address the symlink >> > >> issue, since they are more likely to be nearer the start of the >> > >> path >> > >> than the middle or end. As well as partly the >> > >> privacy/size/same-across-machines issues. >> > >> In any case, I think this easy small change is already very >> > >> useful >> > >> progress. Or does everyone else just fill up .gdbinit with dir >> > >> commands? It seems to me that it shouldn't even that difficult, >> > >> even >> > >> if it isn't very difficult. >> > >> Agreed? >> > >> - Jay >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> From: jayk123 at hotmail.com >> > >> To: m3devel at elegosoft.com >> > >> Subject: re: put full paths to source files in debug info >> > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> > >> ps: does anyone care that binaries built from different cvs >> > >> checkouts, but otherwise identical source, will no longer match, >> > >> unless perhaps they are "stripped"? >> > >> If so, or if any of the other issues bug people, or any other >> > >> problem is brought up or discovered, this can be made a command >> > >> line option. I will always turn it on. :) >> > >> - Jay >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> > >> > To: m3commit at elegosoft.com >> > >> > From: jkrell at elego.de >> > >> > Subject: [M3commit] CVS Update: cm3 >> > >> > >> > >> > CVSROOT: /usr/cvs >> > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> > >> > >> > >> > Modified files: >> > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> > >> > Scanner.m3 >> > >> > >> > >> > Log message: >> > >> > put full paths to source files in debug info >> > >> > >> > >> > This has the minor downsides of: >> > >> > 1) grows the debug info (it is already huge; who is counting?) >> > >> > 2) reveals file system layout in debug info (privacy?) >> > >> > 3) does it inhibit debugging files from other people's >> machines >> > >> or does gdb dir still work? >> > >> > >> > >> > but definitely makes for a more pleasant debugging experience >> > >> when >> > >> > debugging stuff you have built yourself. >> > >> > >> > >> > The linear searching to see if a name has been allocated a >> > >> number yet >> > >> > will obviously slow way down due to a large increase in common >> > >> prefixes, >> > >> > but that should be a hash table anyway. Linear search is lame. >> > >> > (or a trie, but working from the ends of the strings, minus >> the >> > >> last one or few >> > >> > characters, due to common prefixes as well as common suffixes) >> > >> > >> > >> > Note that both m3front and m3cc changes are needed as m3front >> > >> has >> > >> paths >> > >> > relative to the current working directory or such. >> > >> > >> > >> > For most packages, you can get by without the m3front change >> > >> and >> > >> just prepend >> > >> > "../src/" to the path in m3cc, but that doesn't work for >> > >> hierarchical packages >> > >> > such as libm3 and m3core which I am debugging. >> > >> >> ------------------------------------------------------------------------ >> > >> Need to know the score, the latest news, or you need your >> Hotmail?- >> > >> get your "fix". Check it out. > > >> > >> > > >> > > -- >> > > ------------------------------------------------------------- >> > > 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 >> > >> ------------------------------------------------------------------------ >> Need to know the score, the latest news, or you need your Hotmail?- >> get your "fix". Check it out. > > > > -- > ------------------------------------------------------------- > 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 rodney.bates at wichita.edu Fri Feb 29 22:09:47 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 15:09:47 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204305635.13580.82.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> Message-ID: <47C8749B.6070101@wichita.edu> Do you know if this pthread support was in by gdb 6.4? Dragi?a Duri? wrote: > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 22:18:53 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 15:18:53 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <47C83CC7.9060905@wichita.edu> Message-ID: <47C876BD.10003@wichita.edu> Tony Hosking wrote: >> We don't have anything like __FILE__ and __LINE__ in Modula-3. I have a >> largish program full of assertions with it's own coded assertion >> handling, >> including recoverable (in a sense, roll back to a consistent state) >> assertion >> failures. It could use something like this. But it also seems >> pretty hackish >> to me too. > > > Sure we do: > > Compiler.ThisLine() > Compiler.ThisFile() > Thank you. I didn't know about these. -- ------------------------------------------------------------- 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 mika at async.caltech.edu Fri Feb 29 22:19:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 29 Feb 2008 13:19:43 -0800 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: Your message of "Fri, 29 Feb 2008 11:11:35 CST." <47C83CC7.9060905@wichita.edu> Message-ID: <200802292119.m1TLJhcB080697@camembert.async.caltech.edu> "Rodney M. Bates" writes: ... >People can and often do move executables to different machines and also >sometimes move source trees around on the original machine. Using simple >file names within an executable (of which there is always exactly one) >is invariant to all this, and a lot shorter to type/read. ... Arbitrary paths are also not trustworthy on many Unix systems that run automounters. The path you get from getcwd is likely not to be permanently accessible on those. (You access the files via a different path.) Mika From hendrik at topoi.pooq.com Fri Feb 29 23:41:26 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 29 Feb 2008 17:41:26 -0500 Subject: [M3devel] random-acces I/O Message-ID: <20080229224126.GA21397@topoi.pooq.com> I need to do direct-access I/O from a Modula 3 program with a file format that is externally specified. It is necessary to both read and write in random fashion during a run of the program, prefereably without having to close or open the file each time. I expect the answers to the following questions are "Yes", but I'd appreciate confirmation: ? If I have a File.T (obtained from FS.OpenFile) can I have both a Rd.T and a Wr.T active on it simultaeously? ? Will things written using the Wr.T be immediately available for reading with the Rd.T, with no buffereing problems? ? Are there methods for locking the file -- or portions of it -- against simutaneous access by other programs, including ones written in other languages? -- hendrik From dragisha at m3w.org Fri Feb 29 23:09:11 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 29 Feb 2008 23:09:11 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C8749B.6070101@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> <47C8749B.6070101@wichita.edu> Message-ID: <1204322951.13580.87.camel@hias.m3w.org> I think it's in since 6.0 at least. And maybe even as war as 4.17. I am using, when debugging threads, only gdb commands. And it, sort of, works... I still have to try debugger seriously. dd On Fri, 2008-02-29 at 15:09 -0600, Rodney M. Bates wrote: > Do you know if this pthread support was in by gdb 6.4? > > Dragi?a Duri? wrote: > > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > > -- Dragi?a Duri? From jayk123 at hotmail.com Thu Feb 7 05:08:04 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 07 Feb 2008 04:08:04 -0000 Subject: [M3devel] Latest parse.c In-Reply-To: References: Message-ID: >> I don't think it "quits" for us, but worth the printf'ing and such. >> like Sleep(int,record,int,record); >> I wouldn't be surprised if you get @16, but I'm placing no bets here. :) confirmed. Wish I had more to report by now.. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Feb 12 04:29:30 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 12 Feb 2008 03:29:30 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> Message-ID: <47B1168F.8020302@wichita.edu> It sounds like all that Mac OS X needs is for _all_ types in an entire program to use the liberal packing rules. Have I understood correctly? I would have no grief over that. Darko wrote: > The liberalised alignment rules are required for the native Mac OS X > API and should stay. You cannot use that API without them. I think the > pragma is not required and can be removed. I agree with all the points > you make. The effect of the modified alignment rules it to allow > *packed* structures to have members aligned on byte boundaries. This > has the effect of packing the fields in the tightest arrangement > allowed by the platform. This might affect performance, but if the user > is concerned about this they should specify field bit sizes that > deliver improved performance. I don't see a need to specify this on a > structure level, for the reasons you give and because the difference > isn't significant enough in the case of packed structures and their > physical layout and restrictions are platform dependent anyway. > > I might also add that the alignment code is currently broken on > I386_DARWIN. > > - Darko > > > On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > >> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >> being used anywhere? >> >> It is not documented in pragmas.html. The compiler front end appears >> to accept it. (In fact, Decls.m3 contains constants that suggest >> limitations on what declarations the pragma can appear on, but these >> are not actually enforced.) It liberalizes the alignment rules, >> generally allowing scalars to start on any byte boundary. >> >> Pickles have to be able to reconstruct the layout of types as the >> compiler would have done it for a machine (on which a now-being-read >> pickle was written) with different word size and alignment properties. >> Currently, pickles are completely unaware of lazy alignment. It >> would have to be encoded in type descriptions generated by the compiler >> using TipeDesc and read by pickles using RTTipe. >> >> Most troubling to me is what looks like a linguistic Pandora's box. >> The pragma can be associated with any constant, variable, or type >> _declaration_ (not type definition), with the result that different >> values of the same type can actually be different in their alignment >> rules and thus their layout. Similarly for different identifiers >> equated to the same type. Although the effects of this could possibly >> be hidden from the programmer in purely safe code, not so with unsafe >> code. I haven't thoroughly thought this through, but seems to me to >> really fly in the face of the whole typing philosophy of the language. >> >> For example, if pickles were to read in an object value, and there >> were >1 variants of the object's type in the reading program, differing >> only in the alignment rules, how would it decide which one to build? >> In fact, ignoring pickles altogether and just looking at a single >> program, >> if the object's type doesn't actually uniquely give its memory layout, >> how can it be accessed correctly? >> >> Additionally, a quick look at the compiler suggests it won't generate >> correct code for whole record assignment when the LHS and RHS are the >> same type but have different alignment characteristics. >> >> The more I think about it, it seems the only workable possibilities are: >> >> 1) Require the pragma to be associated only with a type _definition_ >> not a >> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make this a >> property of the type that propagates to all names for the type and >> all variables, constants, etc. Also, this would make this property >> a part of the type signature that pickles uses when reading, -OR- >> >> 2) Forget it altogether. >> >> What do people think? >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 darko at darko.org Wed Feb 13 03:20:56 2008 From: darko at darko.org (Darko) Date: Wed, 13 Feb 2008 02:20:56 -0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: <53857.165.228.199.218.1202868771.squirrel@webmail.darko.org> Possibly, but it's a worthy goal. M3 should be deployable on any platform. Too much of the discussion lately seems to be tieing the language to particular platforms, we should be pushing the other way. I'm insterested in working toward a distribution which has no platform APIs, only native M3 interfaces with native strings, traced references only and range checked and enumaterated everything. We should be looking to absact away C interfaces at a low level, not permeate upwards. > My principle concern is that once we provide C APIs then C will > permeate the M3 space more pervasively (both apps and libraries). > What happens when I want to bring up a system where there is no > C?!?! Consider the SPIN OS perhaps... > > Maybe I am just being overly fusty... > > On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > >> What we _maybe_ can do... is to make some special, preprocessable >> source >> form, which some quake command can parse into multiple files in their >> folders. And these file can be compiled later...Kind of how generic >> works. >> >> But, as current system works, and it does it very well, and as only >> case >> where we really need this is Windows... most Unices being or becoming >> POSIX... I don't see it's smart to spend resources on becoming more >> C... >> Esp when "founding fathers" made it so good and so much non-C :). >> >> If we really need to make some approach to "their world", it's much >> better to work on interoperability issues and thus cement our >> first-class-citizen language status even more. >> >> dd >> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >>> Jay: >>> >>> My understanding of Modula-3 is that rather than cluttering up the >>> source code with a bunch of preprocessor directives to deal with the >>> various changes needed by various platforms, a separate source >>> file is >>> used for platforms whose implementation must diverge. The m3makefile >>> is used to control the selection of these platform sources at build >>> time. I like this approach much better. >>> >>> Regards, >>> Randy >>> >>>>>> Jay 2/11/2008 8:21 PM >>> >>> So I have NOT thought this through. >>> >>> I wonder if "preprocessing" dependent only on "target" is a good >>> idea. >>> >>> Something like either the ability to prefix pragmas with a target, or >>> an "iftarget" and "ifnottarget" pragma. >>> >>> Something like so: >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> It's a small can of worms. >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an >>> interface/module). >>> >>> What about IF_OSTYPE? >>> What about expressions? >>> IF_TARGET NT386 OR NTAMD64 >>> >>> IF_TARGET STARTS(NT) >>> >>> etc. >>> >>> I don't really have enough interest here to work through this, just >>> sending out the bait... >>> >>> Obviously this was triggered by my happening into the odbc directory >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >>> conventions with a target. >>> >>> This reminds me of an important point here however -- nobody else is >>> going to make the mistake of ever having multiple calling >>> conventions. >>> Therefore the generality of prefixing WINAPI with NT386: is useless. >>> Unless Mac68K support is added. >>> >>> And here is some rationale even. The PC and Mac evolved from "small" >>> systems, where assembly programming was common, more people knew more >>> lower level details and playing games with calling conventions was >>> something anyone could do. Most other current systems are rooted in C >>> programming. Working in C, calling conventions are generally in a >>> hidden layer below what anyone thinks about. Therefore, the smaller >>> number of capable people working at that level have the good sense to >>> only have one calling convention. No more systems will evolve from >>> "small", at least not without having observed this history. >>> Therefore, >>> there will no longer be multiple calling conventions. >>> >>> That is my theory at least. >>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >>> only x86 >> -- >> Dragi??a Duri?? > > From dabenavidesd at yahoo.es Thu Feb 14 05:56:08 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 14 Feb 2008 04:56:08 -0000 Subject: [M3devel] Modula-3 discussions In-Reply-To: Message-ID: <855460.51998.qm@web27107.mail.ukl.yahoo.com> Hi all: I think that all humans sometimes make mistakes (specially me :), is up to us try to solve them in the best way (I also think there is only one way). I think I don't have enough patience to read the multiple emails Jay write some inspired days (believe me I sometimes don't like to see so many mails from the list even if they are written by Jay or not), however if I am considered and fraternal with all of you I must read it and if I can make some input/comment is a very good think to do it, I think they are very convenient, so for the purpose of a better arguing why we don't try to stay calm and try to understand that the comments of other people are valuable as our opinions are, and learn something important: hear other's opinions. I understand that in a free software project there is always a leader, a head or a principal, maybe this is clear to some of you, but also there are others whom want to make inputs to the development of the project. So two discussions are very clear in the m3devel lasts posts: some of us like more C, some of us like more other languages and some of us like Modula3 as it is, but that doesn't imply that we must change our way of thinking just because we don't agree with some other opinions and the way of continue cm3 development (but we also can question ourselves). We do use the mail for several good purposes but sometimes we forget a important issue: we are saying things to rest of the world that has access to this list, we are trying to get people more involved with the language environment and we don't want to loose users or developers, so it just doesn't matter if we agree with all the opinions of them (I remember one user in the m3devel list some time ago wrote that he has some code and he want to publish it, but I can't fin id it at the moment). I would like to know if It is very rare to try to migrate some part of the programming languages discussion on comp.lang.modula3 and the rest of the most related with cm3 development in m3devel list. Also if we have enough users to try to organize a Modula-3 user group meeting . For instance I know recent research work made by Laszlo Boeszoermenyi, I also can say that in our University (http://www.unal.edu.co) have been deloped in the last 7 years two projects with Modula-3 (one of control and automatization and one of cgi programming), also it was dictated several courses using Modula-3 (there is a set of slides that it's not published yet based on Laszlo's book, I hope this can be give to community if it is important). Why don't try to spend some time making an index of such academic or research and commercial projects, people and institutions towards the benefit of the language developers and it's users. It existed on Michael Dagenais old m3 site a list of modula-3 contributors and enthusiasts: http://web.archive.org/web/20020326115358/http://m3.polymtl.ca/m3/faq/who/ I don't know if it exists on elego source tree tough Also update the acknowledgements of this url: http://modula3.elegosoft.com/pm3/pkg/intro/src/ack.html Well, I almost finishing this "inspired" email, I hope you enjoyed as me :) Thanks you for all the discussion :) and work. --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 15 04:46:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 03:46:43 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> Message-ID: <47B50EDF.8060807@wichita.edu> 1) RTPacking.T and needs to have a separate size for LONGINT, (which can vary independently of the size of INTEGER). 2) Variable length values of subrange bounds found in type descriptions (in TipeDesc.i3) can now have values beyond what the native word size can represent. 3) RTType.Kind.Longint (which I presume you, Tony, added recently) is not handled by Pickles. I have done some coding on this, but have been interrupted. Tony Hosking wrote: > Why is LONGINT for pickles not yet supported? > -- ------------------------------------------------------------- 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 ronny.forberger at elegosoft.com Mon Feb 18 09:37:59 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Mon, 18 Feb 2008 08:37:59 -0000 Subject: [M3devel] Just a mailing list test Message-ID: <20080218093759.x4hxlv3m884wo0s8@mail.elegosoft.com> Please ignore. Ronny -- 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 mika at async.caltech.edu Tue Feb 19 00:09:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 23:09:47 -0000 Subject: [M3devel] code submission In-Reply-To: Your message of "Mon, 18 Feb 2008 19:50:20 GMT." Message-ID: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> That's right, that's approximately what it does. More succinctly, like this :) t.tab : REF ARRAY OF RECORD value : Value.T; next : INTEGER := 0 END; PROCEDURE Get(t : T; READONLY k : ARRAY OF Key.T) : Value.T = VAR p := 0; BEGIN FOR i := FIRST(k) TO LAST(k) DO WITH next = t.tab[p][k[i]].next DO IF next = 0 THEN RETURN t.defValue (* not found *) ELSE p := next END END END; RETURN t.tab[p][k[LAST(k)]].value END Get; Knuth section 6.3 talks about it; he claims the word is based on "information reTRIEval". Tries can be faster than hash methods when most of the words are not to be found in the dictionary, and you can tell by reading just one or two characters that you don't have that word. Parsing a data file in the way what I am doing is an example: I am only interested in a very small subset of the lines. (The application is, given the complete data set for the Toronto Stock Exchange for a month, extract certain records pertaining to a small subset of stock tickers.) Of course, which tickers it is changes all the time, so you can't really compile in a special-case switch statement either. In my application, using the standard Modula-3 TEXT and Text.Hash, plus Text<>Tbl was many times slower than AWK. The trie code is quite a bit faster (completely limited by disk speed). Mika Jay writes: >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >aka "prefix tree" >if I want to recognize the strings, foo, food, fudge, and bar >look at the first character > if it is 'b', go ahead and compare to bar (or the tail to "ar") > if it is 'f' > look at the second character > if it is 'u', go ahead and compare to "fudge" (or the tail to "dge") > if it 'o' > compare the third character > and so on >=20 >Whether or not the data "stops" at unique prefixes is an implementation det= >ail. >If it does, the leaves can contain the entire string or just the tail. >I've fiddled with generating large nested switch statements from a list of = >strings. >I noticed there are many optimizations you can make. >Of course, first you check the length. >Then, really, instead of progressing from left to right, you can pick out c= >haracters with a higher switching factor. >For example if I have the strings foof and food, just look at the last char= >acter. >=20 >As well a hash based algorithm is probably best. >Precompute the hashes of all the strings. >Sor them. >Hash your input string. >Binary search for the hash. >And the compare for an exact match. >=20 >If you are going to do the final compare anyway, then you are going to touc= >h the whole string anyway, you might as well hash it and do a binary search= > I think. Make sure the hash function is fast of course, and not "perfect". >=20 > - Jay >=20 > > > >> Date: Mon, 18 Feb 2008 20:35:36 +0100> From: wagner at elegosoft.com> To: mi= >ka at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cod= >e submission> > Quoting Mika Nystrom :> > > Hello e= >veryone,> >> > I was looking at some code I've written and realized that I = >have a> > very small piece of tested code that may be of interest to other>= > > Modula-3 users. It's a generic "trie" that I coded a few years> > ago. D= >oes anyone have an opinion on adding it to cm3? Where, if so?> >> > http://= >www.async.caltech.edu/~mika/trie/> >> > It's useful for parsing; if you're = >parsing a language with longish> > keywords it is many times faster to use = >this structure and ARRAY> > OF CHAR than using the standard hash tables wit= >h TEXTs. (I developed> > it to parse an old "punch-card", i.e., 80-characte= >r fixed-width> > records, format for financial data.)> > Of course we could= > add this as a small package to m3-libs, or> even to libm3 (it looks rather= > small).> > I hate to sound so uneducated, but what exactly does `trie' sta= >nd for?> It's not contained in my favourite online dictionary either.> > Ol= >af> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-A= >llee 25 / Geb=E4ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mo= >bile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | = >Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgerich= >t Charlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >aka "prefix tree"

>if I want to recognize the strings, foo, food, fudge, and bar
>look at the first character
>  if it is 'b', go ahead and compare to bar (or the tail to "ar")
>  if it is 'f'
>   look at the second character
>     if it is 'u', go ahead and compare to "fudge" (or = >the tail to "dge")
>     if it 'o'
>        compare the third character
>        and so on
> 
>Whether or not the data "stops" at unique prefixes is an implementation det= >ail.
>If it does, the leaves can contain the entire string or just the tail.
>
I've fiddled with generating large nested switch statements from a list= > of strings.
>I noticed there are many optimizations you can make.
>Of course, first you check the length.
>Then, really, instead of progressing from left to right, you can pick out c= >haracters with a higher switching factor.
>For example if I have the strings foof and food, just look at the last char= >acter.
> 
>As well a hash based algorithm is probably best.
>Precompute the hashes of all the strings.
>Sor them.
>Hash your input string.
>Binary search for the hash.
>And the compare for an exact match.
> 
>If you are going to do the final compare anyway, then you are going to touc= >h the whole string anyway, you might as well hash it and do a binary search= > I think. Make sure the hash function is fast of course, and not "perfect".= >
> 
> - Jay
> 
> >
>
>> Date: Mon, 18 Feb 2008 20:35:36 +0100
> From: wagner at elegosoft.c= >om
> To: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
= >> Subject: Re: [M3devel] code submission
>
> Quoting Mika N= >ystrom <mika at async.caltech.edu>:
>
> > Hello everyone= >,
> >
> > I was looking at some code I've written and rea= >lized that I have a
> > very small piece of tested code that may b= >e of interest to other
> > Modula-3 users. It's a generic "trie" t= >hat I coded a few years
> > ago. Does anyone have an opinion on ad= >ding it to cm3? Where, if so?
> >
> > http://www.async.ca= >ltech.edu/~mika/trie/
> >
> > It's useful for parsing; if= > you're parsing a language with longish
> > keywords it is many ti= >mes faster to use this structure and ARRAY
> > OF CHAR than using = >the standard hash tables with TEXTs. (I developed
> > it to parse = >an old "punch-card", i.e., 80-character fixed-width
> > records, f= >ormat for financial data.)
>
> Of course we could add this as = >a small package to m3-libs, or
> even to libm3 (it looks rather small= >).
>
> I hate to sound so uneducated, but what exactly does `t= >rie' stand for?
> It's not contained in my favourite online dictionar= >y either.
>
> Olaf
>
>
>
> --
&= >gt; Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee= > 25 / Geb=E4ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96= > mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegos= >oft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelreg= >ister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>= >


Connect and share in new ways with Windows Live. ef=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelif= >e_012008' target=3D'_new'>Get it now! >= > >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_-- From wagner at elegosoft.com Tue Feb 19 00:30:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 23:30:50 -0000 Subject: [M3devel] code submission In-Reply-To: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> References: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> Message-ID: <20080219003049.nmeda2ky8880ksss@mail.elegosoft.com> Quoting Mika Nystrom : > Knuth section 6.3 talks about it; he claims the word is based on > "information reTRIEval". Tries can be faster than hash methods > when most of the words are not to be found in the dictionary, and > you can tell by reading just one or two characters that you don't > have that word. Parsing a data file in the way what I am doing is > an example: I am only interested in a very small subset of the > lines. (The application is, given the complete data set for the > Toronto Stock Exchange for a month, extract certain records pertaining > to a small subset of stock tickers.) Of course, which tickers it > is changes all the time, so you can't really compile in a special-case > switch statement either. > In my application, using the standard Modula-3 TEXT and Text.Hash, > plus Text<>Tbl was many times slower than AWK. The trie code is quite > a bit faster (completely limited by disk speed). OK, thanks for the explanations. I should have a look at the old standard books more often. I know prefix trees, but had never heard the term `trie'. I think we should definitely add it. I'm still not sure if it should go better into its own package or into the generics part of libm3. What do the others 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 darko at darko.org Tue Feb 19 01:32:07 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 00:32:07 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> We seem to be going through these same point several times. I'm not sure what the difficulty is, I'm just repeating myself. Keep in mind this applies *only* to packed structures, ie BIT FOR or bit fields. The change I put in libralised the *M3* alignment rules so that BITS FOR fields in structures would align on byte boundries if possible instead of restricting them to word alignment generally. GCC happily generates code for this. There may be restrictions in GCC's C as to how you can arrange bit fields but I don't see what they have to do with M3. This is absolutely essentail for using the native APIs on Mac OS X and its removal would make M3 pointless for use on the Mac, at least more me. This should be the default behviour. If you are using BITS FOR it's becuase you want to arrange the fields in a record in particular way. Why then arbitrarliy pad out the fields? If performance is an issue, the user should be using appropriate field bit sizes. The implementation rule for BITS FOR in M3 is implementation dependent, there are no language issues. The LAZYALIGN pragma (that is, the prgama itself) is something Olaf created and had nothing to do with me. I diagreed with it and never used it in the version of the compiler I ran. I support its removal. > On Feb 18, 2008, at 3:01 PM, Darko wrote: > >> The alignment behaviour is absolutely crucial to programming >> natively in Mac OS X and should be kept. I have a great need for it. >> >> The PRGAMA is of no use and can be removed. >> >> Does anyone have any objections to making this alignment behaviour >> standard? > > What do you mean make LAZYALIGN standard? Why wouldn't we go with > the standard gcc-backend alignment? Perhaps I don't understand what > it is you are doing or trying to do. Again, please remind me what it > is that LAZYALIGN does and why it is needed. > >> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >> >>> Can someone remind me again why we need LAZYALIGN? I concur with >>> Randy that if it is rarely used and moreso breaks things I would >>> argue to abandon it. >>> >>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>> >>>> I use pickles extensively and they are used also by network objects. >>>> I've never used LAZYALIGN. >>>> My vote is that we don't break something (pickles/netobj) to add >>>> support for something that is rarely used. >>>> Regards, >>>> Randy >>>> >>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>> PM >>> >>>> I'll put it in comments in the code. I am sure I can fix it to >>>> handle LAZYALIGN too, just not sure whether I can do it without >>>> requiring existing pickle files to be regenerated and/or existing >>>> code that reads/writes pickles to need recompilation. >>>> >>>> Anybody on this list who has code that might be affected if pickles >>>> or compiled code were invalidated by a change? >>>> >>>> I do propose we change the way of telling the compiler to do >>>> LAZYALIGN so that it is a property of a type and affects all >>>> variables of that type. >>>> >>>> Olaf Wagner wrote: >>>> > Perhaps we should check-in this description somewhere near the >>>> > actual code? Or is there enough documentation already? >>>> > >>>> > Olaf >>>> > >>>> > PS: Based on your description, I'd say we should abandon >>>> LAZYALIGN. >>>> > Or at least put a big sticker on that it will break pickles. >>>> > >>>> > Quoting "Rodney M. Bates" : >>>> > >>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>> BITSIZE, >>>> >> etc. only works for getting object layouts as on the machine >>>> executing >>>> >> the code, which is all that is needed when writing a pickle. >>>> >> >>>> >> When reading, Pickle code needs to know the layouts of a type >>>> both as >>>> >> it is on the reading machine and as it was on the machine that >>>> wrote >>>> >> the pickle. The type description that the compiler generates is >>>> >> excerpted and contains no field displacements, just lists of >>>> field >>>> >> types (which are either recursive type descriptions or builtin >>>> types). >>>> >> So it is independent of word sizes, etc. >>>> >> >>>> >> Pickles regenerates the displacements using the few target >>>> machine >>>> >> characteristics in a RTPacking.T It traverses a type >>>> description and >>>> >> simultaneously computes two sets of field displacements, both >>>> as they >>>> >> are on the reading machine and on the writing machine. For >>>> the latter, >>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>> stored in the >>>> >> header of the pickle file. For the former, it's gotten by >>>> techniques >>>> >> like >>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>> m3core, and >>>> >> called by Pickle code. >>>> >> >>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>> layout >>>> >> behavior. There is no shared code. Making it common would >>>> involve >>>> >> quite a bit of rework, as the two use substantially different >>>> data >>>> >> structure and code organization. It will be obvious what kind >>>> of bit >>>> >> damage could occur if the two algorithms didn't agree. >>>> >> >>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>> comparing the >>>> >> field displacement computations in RTTipe and in the >>>> compiler. The >>>> >> former is oblivious to LAZYALIGN. >>>> >> >>>> >> Note that all this is required even without any packing of >>>> small fields >>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>> on a >>>> >> 32-bit machine and unpickled on a 64. >>>> >> >>>> >> Tony Hosking wrote: >>>> >> >>>> >>> Rodney, >>>> >>> >>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>> >>> would have thought all packing is done on word-sized units >>>> anyway. >>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>> figure >>>> >>> out what to do presumably no differently from the way >>>> INTEGER is >>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>> >>> something? >>>> >>> >>>> >>> -- Tony >>>> >>> >>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>> >>> >>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>> help with? >>>> >>>> >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>> >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> >>>>> (which can vary independently of the size of INTEGER). >>>> >>>>> 2) Variable length values of subrange bounds found in type >>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> >>>>> what the native word size can represent. >>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>> recently) >>>> >>>>> is not handled by Pickles. >>>> >>>>> >>>> >>>>> I have done some coding on this, but have been interrupted. >>>> >>>>> >>>> >>>>> Tony Hosking wrote: >>>> >>>>> >>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> ------------------------------------------------------------- >>>> >>>>> 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 >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >> >>>> >> -- >>>> >> ------------------------------------------------------------- >>>> >> 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 >>>> > >>>> > >>>> > >>>> > >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 rodney.bates at wichita.edu Tue Feb 19 03:00:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 19 Feb 2008 02:00:36 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B9644F.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> Message-ID: <47BA3AC5.40907@wichita.edu> Just to clarify: I don't believe anything existing has to break. The worst scenario I can see is that you would have to either simultaneously upgrade the compiler, libm3, and libm3core (or else none of these) before recompiling & linking any code that reads or writes pickles. If libm3 and libm3core are dynamically linked in at runtime, you would have to recompile with an upgraded compiler at the same time as installing the upgraded dynamic libraries. Existing pickle files would not change. Also, mixtures of programs thus recompiled & linked and programs not recompiled/linked could exchange pickle files. Anything that (un)pickles records or objects that are LAZYALIGN would need the upgrade to work, but such programs are already broken. Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add support > for something that is rarely used. > Regards, > Randy > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Sat Feb 23 04:43:22 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 23 Feb 2008 03:43:22 -0000 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> Message-ID: <47BF99F0.9050402@wichita.edu> Yes, most of this is done in RTTipe. I tend to speak sloppily about this as "pickles", which are, I believe, the only client code of RTTipe in the CM3 distribution. Darko wrote: > Then I assume RTTipe needs to be fixed, and pickles and the alignment > are ok. > >-- ------------------------------------------------------------- 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 Sun Feb 24 16:11:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:11:44 +0100 Subject: [M3devel] Pathname.T extensions, was: Re: exposing both path name types? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: <20080224161144.zgi5zplzk8sgcc8s@mail.elegosoft.com> Actually I think it's a good idea to provide platform-specific interfaces for pathnames in libm3. This way programs can use the common pathname abstraction in general and special features of target specific pathnames if they need to. Especially when programming in a mixed Windows/POSIX environment this will help to keep things simpler. I'd suggest something like this: extends Pathname.T <---- PathnamePosix.T <---- PathnameWindows/NTFS.T <---- PathnameCygwin.T <---- [PathnameDos/FAT.T] (probably no need currently) <---- [PathnameOS2.T] (probably no need currently) (An alternative hinted at above would be to name interfaces after the actual file systems; there could be different implementations for UFS, ZFS, NTFS, FAT, HFS, SMBFS, etc. then. This may go too far though.) Pathname.T should keep all the abstractions that are curently there; nothing must be changed syntactically or semantically. It may be extended by an equal predicate (and thus abstract from case differences if needed) and perhaps more useful methods (arcSeparatorChar/Text(), hasPlatformSpecificRoot(), ...). PathnameWindows.T could extend the functionality by methods for handling of drives and UNC syntax; PathnameCygwin.T could contain support for /cygdrive/... conversion etc. All Pathname modules should only depend on pure TEXT functions (i.e. not platform specific library calls etc.). All derived types should implement initialization methods for conversions: initFromPosix( PathnamePosix.T ) initFromWindows( PathnameWindows.T ) initFromCygwin( PathnameCygwin.T ) Specialized applications like the CM3 builder which are platform specific to a certain extend could then use standard function calls to convert between different pathname representations as needed. Again, I think we should first exactly define the interfaces, and then provide some unit tests. I'll see if I can find some old tests as a start. BTW, the quake functions that were part of the original proposal I sent to the list are not implemented in quake because they were not really thought over well; if there are implementations of these in M3 (sysutils), these are just historic relicts and probably not very general and powerful. What do the others think? Olaf Quoting Jay : > What is the idiom for this: > > Currently: > There is Pathname.i3. > PathnamePosix EXPORTS Pathname > PathnameWin32 EXPORTS Pathname > You can only have one in a link. > > It would seem possibly useful to have: > Pathname.i3 unchanged > PathnamePosix.i3 identical to Pathname.i3 (some what to avoid the > duplication?) > PathnameWin32.i3 identical to Pathname.i3 (ditto) > > On Posix targets: > PathnameWin32.m3 exports just PathnameWin32 > PathnamePosix exports both PathnamePosix and Pathname > > On Windows targets: > PathnamePosix exports just PathnamePosix > PathnameWin32 exports both PathnameWin32 and Pathname > > That is Pathname.Foo resolves statically at compile time to the > target-specific library. > PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. > > These modules each import nothing, except Text. They do all their > string manipulation themselves. > > Olaf's recent Quake extensions document but don't implement > pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( > pn ) --> text > As long as pn is a fullpath, these are easy, I just wrote up > prototypes, haven't compiled them. > > I think these functions might suggest doing what I'm asking about as > well, maybe. > Or maybe you'd just convert and then never pick back apart. > > I have sleazed by for now by using subst_text / to \ and setting up > NTFS junctions. > In this way, I can cross build NT386 <=> NT386GNU either host, either target. > Had I not done anything, the linker interprets > /cygdrive/c/foo/bar.lib as a command switch and says it doesn't > understand it. > Not a big deal, but I think there might be some easy progress here. > > This is not just about Pathname. > > It is also about File. > Even though NT386GNU File is FilePosix, it would be useful to allow > the serial package to use FileWin32 instead. > But FilePosix and FileWin32 both reveal the same types. > It'd be nice if they could expose FilePosix.T and FileWin32.T and > then only one of them reveal File.T = FilePosix.T or File.T = > FileWin32.T, something like that. > > > - Jay > _________________________________________________________________ > Climb to the top of the charts! Play the word scramble challenge > with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Feb 24 16:32:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:32:05 +0100 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> Message-ID: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Quoting Jay : > Oh darn, inevitably that is not my final answer.. > more like attached.. Jay, the files seem to work OK on my FreeBSD system. But the tinderbox tests on birch and new have failed, in spite of my CVS revert; so please don't commit anything until I have found out what is wrong. It may take some time, because I'm expecting guests soon and won't be able to do much until tomorrow evening. Olaf > - Jay > > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000 > > > Olaf can you try the attached? Thanks, - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Feb 27 03:49:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 21:49:50 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> Message-ID: On Feb 26, 2008, at 6:46 PM, Jay wrote: > Tony, what about the need to copy? The inability to iterate through > characters without a function call per character? I guess though, > from what you pointed out, a read only direct pointer is viable. And > that removes the 256 character stack usage -- which is a bit piggy > as it is. So then..I guess the next step in some compromise here is > that it should perhaps be viable to get a read only pointer to a > string (maybe already the case), compute the required size of the > new one (follows naturally), and then be able to split up allocation > and filling in of a string, a function to allocate and get a direct > pointer, then fill in your data, then "seal" the text making it read > only. And I guess really you can just carefully use the "subversive" > method here -- up to you to not pass the "unsealed" text off to > anyone else until you are done writing to it. Have you looked at TextConv.i3? Not sure if that has some of what you are needing. > Then just to deal with the varying representation but as I was > suggesting, maybe that can be forced somehow. > Maybe creation can specify an encoding, or the "get buffer" function > could -- though ideally there is just one, not two. > > The stack vs. heap behavior is also not ideal in that it's nice for > the performance of something to scale linearly with input, not > suddenly slow way down when data exceeds some arbitrary threshold. > Granted, a lot of code just starts failing, so merely slowing down > is "progress". As well, eventually you end up swapping to disk, if > you don't first run out of address space, so there will be limits at > which things slow down or fail, just that they ought to be fairly > large. Why do you think that heap allocation is slow in general? > I also rather hoped/assumed that compile time text constants were > formed constant-ly by the compiler, that the compiler knows their > runtime layout. I realize the division of labor between compiler and > runtime can be made at varying points, with varying resulting > flexibility, but also varying resulting efficiency. Compile-time literals *are* formed constantly by the compiler. They are TextLiteral.T. > > > - Jay > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Tue, 26 Feb 2008 17:43:17 -0500 > Subject: Re: [M3devel] text inefficiency? good mutable string type? > arrays? > > I suppose the question here is how often you exceed the 256- > character stack-allocated buffer size? If not often then > occasionally allocating in the heap is not a huge problem. I'm not > too fussed about this anyway because generational GC will quickly > reclaim things that die as young as this buffer does. I think you > underestimate the effectiveness of modern GC algorithms. Anyway, > optimizing here for short nm texts presumably handles the common > case. Why work hard to optimize the uncommon case? > > On Feb 25, 2008, at 10:38 AM, Jay wrote: > > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > Here is some apparently typical code: > > PROCEDURE Escape (nm: TEXT): TEXT = > VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (nm = NIL) THEN RETURN NIL; END; > len := Text.Length (nm); > IF (len + len <= NUMBER (buf)) > THEN RETURN DoEscape (nm, len, buf); > ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + > len)^); > END; > END Escape; > > PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF > CHAR): TEXT = > VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; > BEGIN > Text.SetChars (buf, nm); > FOR i := 0 TO len-1 DO > IF (buf[i] = BackSlash) THEN INC (n_escapes); END; > END; > IF (n_escapes = 0) THEN RETURN nm; END; > src := len - 1; > dest := src + n_escapes; > WHILE (src > 0) DO > c := buf[src]; DEC (src); > buf[dest] := c; DEC (dest); > IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); > END; > END; > RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); > END DoEscape; > > > Look at how inefficient this is. > For a long string it makes a heap allocation, even if in the end it > makes no changes to the string. > For any length string it copies it out to an array. > Then if there are any changes, it copies it again, probably into > heap, likely the input immediately becoming garbage. > Heap allocation may be fast, but building up garbage and causing > more work for the garbage collector I assume is bad. > And if the string had no backslashes, it's all a big waste. > > I assume texts are read only? > > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > > > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed? > Not necessarily in the language but in m3core or libm3? > Maybe it's already there? > > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a > good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => > wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not > characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:59:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:59:51 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 03:00:38 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 02:00:38 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: (sorry for the double, email problems) From: jayk123 at hotmail.com If this must be a switch, what should the default be? _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 1 15:33:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 01 Feb 2008 08:33:43 -0600 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> Message-ID: <47A32DC7.5080909@wichita.edu> Ah, and this is a systematic way of ensuring the precondition a.n=b.n always holds. Does the MIN function hint at someday generalizing to not require this condition? That would be tidy, but seems like an awful lot of work, if it is never used. Tony Hosking wrote: > Hi Rodney, > > Yes, you are missing one crucial thing. Namely, that the front-end > compiler *carefully* uses these target integer simulations only with > values that are *explicitly* the same length. LONGINT and INTEGER are > different types. INTEGER is the *representation* type for all values > 32 bits or less. LONGINT is the representation type for only LONGINT > values. You cannot mix LONGINT with INTEGER in source code > expressions. They need to be converted explicitly using ORD/VAL. > Indeed, you are right that the interfaces should document that behavior > explicitly, or alternatively, perhaps the implementations should > <*ASSERT a.n=b.n*>. The change from the way PM3 does things was > necessary for the introduction of LONGINT. > > Hope this helps and sorry for the imprecision of documentation. > > On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: > >> Whenever I run across something this unbelievable, I figure I must >> be missing something. Can anybody tell me what? >> >> While working on making Pickles work on LONGINT, I have noted the >> following code snippets for doing target arithmetic at compile time: >> >> From m3-sys/m3middle/src/Target.i3: >> >> (* The bits of a target INTEGER (in 2's complement) are stored in >> an array of small host values, with the low order bits in the first >> element of the array. *) >> >> TYPE >> Int = (* OPAQUE *) RECORD >> n: CARDINAL; (* only bytes [0..n-1] contain valid bits *) >> x := IBytes{0,..}; (* default is Zero *) >> END; >> IBytes = ARRAY [0..7] OF IByte; >> IByte = BITS 8 FOR [0..16_ff]; >> >> From m3-sys/m3middle/src/TWord.m3: >> >> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >> VAR borrow := 0; n := MIN (a.n, b.n); >> BEGIN >> <*ASSERT n # 0*> >> r.n := n; >> FOR i := 0 TO n-1 DO >> borrow := a.x[i] - b.x[i] - borrow; >> r.x[i] := Word.And (borrow, Mask); >> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >> END; >> END Subtract; >> >> Unless the two values have equal numbers of bytes, Subtract just >> throws away the high bytes of the longer operand. It looks like >> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >> does this. >> >> It seems just about inconceivable that the arithmetic could be this >> broken and not have created many impossible-to-ignore bugs. SRC >> and pm3 do it differently. They have a single global variable that >> gives the used size of all CT target values. >> >> The only possible explanation I can think of is that the cm3 compiler >> happens never to pass two Target.Int values with different values of n. >> The relevant declarations give no hint of such a counter-intuitive >> requirement. If this is an essential precondition, it should be >> documented in the interfaces. >> >> -- >> ------------------------------------------------------------- >> 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 >> >> > > -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 1 20:57:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 14:57:15 -0500 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <47A32DC7.5080909@wichita.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> <47A32DC7.5080909@wichita.edu> Message-ID: <02DFFA0A-3768-413C-8D84-0354BC9CB08A@cs.purdue.edu> On Feb 1, 2008, at 9:33 AM, Rodney M. Bates wrote: > Ah, and this is a systematic way of ensuring the precondition > a.n=b.n always holds. Does the MIN function hint at someday > generalizing to not require this condition? Yes, that's the general idea. > That would be tidy, > but seems like an awful lot of work, if it is never used. Yeah, I played around with this a great deal and decided it wasn't worth the effort. > > Tony Hosking wrote: >> Hi Rodney, >> Yes, you are missing one crucial thing. Namely, that the front- >> end compiler *carefully* uses these target integer simulations >> only with values that are *explicitly* the same length. LONGINT >> and INTEGER are different types. INTEGER is the *representation* >> type for all values 32 bits or less. LONGINT is the >> representation type for only LONGINT values. You cannot mix >> LONGINT with INTEGER in source code expressions. They need to be >> converted explicitly using ORD/VAL. Indeed, you are right that >> the interfaces should document that behavior explicitly, or >> alternatively, perhaps the implementations should <*ASSERT >> a.n=b.n*>. The change from the way PM3 does things was necessary >> for the introduction of LONGINT. >> Hope this helps and sorry for the imprecision of documentation. >> On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: >>> Whenever I run across something this unbelievable, I figure I must >>> be missing something. Can anybody tell me what? >>> >>> While working on making Pickles work on LONGINT, I have noted the >>> following code snippets for doing target arithmetic at compile time: >>> >>> From m3-sys/m3middle/src/Target.i3: >>> >>> (* The bits of a target INTEGER (in 2's complement) are stored in >>> an array of small host values, with the low order bits in the >>> first >>> element of the array. *) >>> >>> TYPE >>> Int = (* OPAQUE *) RECORD >>> n: CARDINAL; (* only bytes [0..n-1] contain valid >>> bits *) >>> x := IBytes{0,..}; (* default is Zero *) >>> END; >>> IBytes = ARRAY [0..7] OF IByte; >>> IByte = BITS 8 FOR [0..16_ff]; >>> >>> From m3-sys/m3middle/src/TWord.m3: >>> >>> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >>> VAR borrow := 0; n := MIN (a.n, b.n); >>> BEGIN >>> <*ASSERT n # 0*> >>> r.n := n; >>> FOR i := 0 TO n-1 DO >>> borrow := a.x[i] - b.x[i] - borrow; >>> r.x[i] := Word.And (borrow, Mask); >>> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >>> END; >>> END Subtract; >>> >>> Unless the two values have equal numbers of bytes, Subtract just >>> throws away the high bytes of the longer operand. It looks like >>> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >>> does this. >>> >>> It seems just about inconceivable that the arithmetic could be this >>> broken and not have created many impossible-to-ignore bugs. SRC >>> and pm3 do it differently. They have a single global variable that >>> gives the used size of all CT target values. >>> >>> The only possible explanation I can think of is that the cm3 >>> compiler >>> happens never to pass two Target.Int values with different >>> values of n. >>> The relevant declarations give no hint of such a counter-intuitive >>> requirement. If this is an essential precondition, it should be >>> documented in the interfaces. >>> >>> -- >>> ------------------------------------------------------------- >>> 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 >>> >>> > > -- > ------------------------------------------------------------- > 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 Fri Feb 1 21:26:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 01 Feb 2008 21:26:30 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> References: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> Message-ID: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 2 00:57:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 18:57:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080201234353.F351E10D4655@birch.elegosoft.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> Message-ID: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> I just checked in support for full declaration of paramters even on imported procedures in the gcc-based backend. This is to support proper generation of stdcall calling convention on Windows. In the process of testing this I discovered that cm3 on non-Windows platforms now needs to build and ship both of the Windows x86 support libraries m3back and m3objfile, even though non-Windows platforms don't use or need them. This seems broken to me. It seems that cm3 has changed so that it now has these dependencies. Can we please undo this? -- I see no need to have to build these for non-x86 platforms that will never use them. On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 08/02/02 00:43:53 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Add parameter decls even for imported procedures, as per Jay > Krell's request > to support stdcall parameter passing mode on Windows. From jayk123 at hotmail.com Sat Feb 2 01:12:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:12:27 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...). Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well? Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly. ? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 01:19:05 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:19:05 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Actually it's slightly more real than I said. One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. Sometimes it uses the "extra" code, sometimes not. These are in a sense a limited form of cross build. Granted, if it was only for those three psuedo platforms, you wouldn't mind. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hosking at elego.deDate: Sat, 2 Feb 2008 00:12:27 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...).Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well?Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly.? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:22:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:22:56 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, that gnarly x86 backend will go away soon anyway -- it's probably never going to survive in the x86_64 universe and beyond! On Feb 1, 2008, at 7:19 PM, Jay wrote: > Actually it's slightly more real than I said. > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > Sometimes it uses the "extra" code, sometimes not. These are in a > sense a limited form of cross build. Granted, if it was only for > those three psuedo platforms, you wouldn't mind. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; hosking at elego.de > Date: Sat, 2 Feb 2008 00:12:27 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > This was deliberate. It enables some cross-build scenarios. That I > admit I haven't used (yet?), but I really like the idea. > If m3linker were completed, then "full" cross builds would be real. > > The "extra" packages are small and build fast (well, at least not > using cm3cg...). > Is it really so onerous? Really? > > Isn't it nice to have less filtering of packages as well? > Like, when you are building on non-NT386, you can easily see that > you didn't break building on NT386, at least partly. > ? > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > To: hosking at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I just checked in support for full declaration of paramters even on > > imported procedures in the gcc-based backend. This is to support > > proper generation of stdcall calling convention on Windows. In the > > process of testing this I discovered that cm3 on non-Windows > > platforms now needs to build and ship both of the Windows x86 > support > > libraries m3back and m3objfile, even though non-Windows platforms > > don't use or need them. This seems broken to me. It seems that cm3 > > has changed so that it now has these dependencies. Can we please > > undo this? -- I see no need to have to build these for non-x86 > > platforms that will never use them. > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > Add parameter decls even for imported procedures, as per Jay > > > Krell's request > > > to support stdcall parameter passing mode on Windows. > > > > > Connect and share in new ways with Windows Live. Get it now! > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From jayk123 at hotmail.com Sat Feb 2 01:45:25 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:45:25 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:22:56 -0500> To: jayk123 at hotmail.com> > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond!> > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > > Actually it's slightly more real than I said.> > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu; hosking at elego.de> > Date: Sat, 2 Feb 2008 00:12:27 +0000> > CC: m3devel at elegosoft.com> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> >> > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea.> > If m3linker were completed, then "full" cross builds would be real.> >> > The "extra" packages are small and build fast (well, at least not > > using cm3cg...).> > Is it really so onerous? Really?> >> > Isn't it nice to have less filtering of packages as well?> > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly.> > ?> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > To: hosking at elego.de> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > >> > > I just checked in support for full declaration of paramters even on> > > imported procedures in the gcc-based backend. This is to support> > > proper generation of stdcall calling convention on Windows. In the> > > process of testing this I discovered that cm3 on non-Windows> > > platforms now needs to build and ship both of the Windows x86 > > support> > > libraries m3back and m3objfile, even though non-Windows platforms> > > don't use or need them. This seems broken to me. It seems that cm3> > > has changed so that it now has these dependencies. Can we please> > > undo this? -- I see no need to have to build these for non-x86> > > platforms that will never use them.> > >> > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > >> > > > CVSROOT: /usr/cvs> > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > >> > > > Modified files:> > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > >> > > > Log message:> > > > Add parameter decls even for imported procedures, as per Jay> > > > Krell's request> > > > to support stdcall parameter passing mode on Windows.> > >> >> >> > Connect and share in new ways with Windows Live. Get it now!> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:56:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:56:18 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> It would be nice to have the x86 integrated backend for I386_LINUX and LINUXLIBC6 too -- just like the old PM3 did. On Feb 1, 2008, at 7:45 PM, Jay wrote: > Hey, I'd kind of like that backend to stay actually. It's quite > fast and generates better code than unoptimized gcc and competitive > code with optimized gcc. There's no AMD64 support anywhere yet in > Modula-3 that I know of. Maybe it will appear here first? :) > > I don't think it is all that gnarly either. But somewhat. It's a > bit like code I've see that is so often handling one case after > another case after yet another case, yet who knows what all the > cases are and which order (if any particular) they should be > handled in? That is, it's actually kind of easier to read it and > understand what it does do, and realize that is "correct" in the > "necessary" sense, but hard to know if it is "sufficient". > I've got outstanding diffs for int64 support I'd like to get back to. > > AMD64 shouldn't be difficult...that's kind of the point, eh? > It's just a slight alteration of x86.. > > Granted, it isn't set up, doesn't have a "framework", to generate > substantially better code. > It doesn't remember much, doesn't make multiple passes, doesn't > have a high level representation, etc. > > In the unlikely event that I succeed, presumably PPC would be > next...:) > > (But yeah yeah, LLVM is probably easier and much more fruitful, > both in terms of platform each and optimization..and hopefully > build speed.) > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > To: jayk123 at hotmail.com > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > that gnarly x86 backend will go away soon anyway -- it's probably > > never going to survive in the x86_64 universe and beyond! > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > Actually it's slightly more real than I said. > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > sense a limited form of cross build. Granted, if it was only for > > > those three psuedo platforms, you wouldn't mind. > > > > > > - Jay > > > > > > From: jayk123 at hotmail.com > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > admit I haven't used (yet?), but I really like the idea. > > > If m3linker were completed, then "full" cross builds would be > real. > > > > > > The "extra" packages are small and build fast (well, at least not > > > using cm3cg...). > > > Is it really so onerous? Really? > > > > > > Isn't it nice to have less filtering of packages as well? > > > Like, when you are building on non-NT386, you can easily see that > > > you didn't break building on NT386, at least partly. > > > ? > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > To: hosking at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > I just checked in support for full declaration of paramters > even on > > > > imported procedures in the gcc-based backend. This is to support > > > > proper generation of stdcall calling convention on Windows. > In the > > > > process of testing this I discovered that cm3 on non-Windows > > > > platforms now needs to build and ship both of the Windows x86 > > > support > > > > libraries m3back and m3objfile, even though non-Windows > platforms > > > > don't use or need them. This seems broken to me. It seems > that cm3 > > > > has changed so that it now has these dependencies. Can we please > > > > undo this? -- I see no need to have to build these for non-x86 > > > > platforms that will never use them. > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > CVSROOT: /usr/cvs > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > Modified files: > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > Log message: > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > Krell's request > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From rcoleburn at scires.com Sat Feb 2 01:57:24 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 19:57:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <47A379A4.1E75.00D7.1@scires.com> I too want to keep that backend. All of my Modula-3 production code in the past was built using it. Regards, Randy >>> Jay 2/1/2008 7:45 PM >>> Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:22:56 -0500 > To: jayk123 at hotmail.com > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond! > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > Actually it's slightly more real than I said. > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu; hosking at elego.de > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea. > > If m3linker were completed, then "full" cross builds would be real. > > > > The "extra" packages are small and build fast (well, at least not > > using cm3cg...). > > Is it really so onerous? Really? > > > > Isn't it nice to have less filtering of packages as well? > > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly. > > ? > > > > - Jay > > > > > > > From: hosking at cs.purdue.edu > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > To: hosking at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > I just checked in support for full declaration of paramters even on > > > imported procedures in the gcc-based backend. This is to support > > > proper generation of stdcall calling convention on Windows. In the > > > process of testing this I discovered that cm3 on non-Windows > > > platforms now needs to build and ship both of the Windows x86 > > support > > > libraries m3back and m3objfile, even though non-Windows platforms > > > don't use or need them. This seems broken to me. It seems that cm3 > > > has changed so that it now has these dependencies. Can we please > > > undo this? -- I see no need to have to build these for non-x86 > > > platforms that will never use them. > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > Modified files: > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > Log message: > > > > Add parameter decls even for imported procedures, as per Jay > > > > Krell's request > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Shed those extra pounds with MSN and The Biggest Loser! Learn more. ( http://biggestloser.msn.com/ ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:02:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:02:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sat Feb 2 02:08:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 20:08:59 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <47A37C5A.1E75.00D7.1@scires.com> Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy >>> Jay 2/1/2008 8:02 PM >>> "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:56:18 -0500 > To: jayk123 at hotmail.com > > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did. > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient". > > I've got outstanding diffs for int64 support I'd like to get back to. > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > It's just a slight alteration of x86.. > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code. > > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc. > > > > In the unlikely event that I succeed, presumably PPC would be > > next...:) > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.) > > > > - Jay > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > To: jayk123 at hotmail.com > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > that gnarly x86 backend will go away soon anyway -- it's probably > > > never going to survive in the x86_64 universe and beyond! > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > Actually it's slightly more real than I said. > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > > sense a limited form of cross build. Granted, if it was only for > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > > admit I haven't used (yet?), but I really like the idea. > > > > If m3linker were completed, then "full" cross builds would be > > real. > > > > > > > > The "extra" packages are small and build fast (well, at least not > > > > using cm3cg...). > > > > Is it really so onerous? Really? > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > Like, when you are building on non-NT386, you can easily see that > > > > you didn't break building on NT386, at least partly. > > > > ? > > > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > To: hosking at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > I just checked in support for full declaration of paramters > > even on > > > > > imported procedures in the gcc-based backend. This is to support > > > > > proper generation of stdcall calling convention on Windows. > > In the > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > platforms now needs to build and ship both of the Windows x86 > > > > support > > > > > libraries m3back and m3objfile, even though non-Windows > > platforms > > > > > don't use or need them. This seems broken to me. It seems > > that cm3 > > > > > has changed so that it now has these dependencies. Can we please > > > > > undo this? -- I see no need to have to build these for non-x86 > > > > > platforms that will never use them. > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > Modified files: > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > Log message: > > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > > Krell's request > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more. > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:19:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:19:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47A37C5A.1E75.00D7.1@scires.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> <47A37C5A.1E75.00D7.1@scires.com> Message-ID: No. (I fully admit I don't know yet what the problem is, and the way the system is designed in my understanding, variations like this are "impossible", therefore throw out nearly all expectations and entertain nearly all ideas, but I don't think this is related. It'll just have to be debugged and code studied and skimmed for hints, and I apologize for the long delay. Maybe some code checks for function equality?? (not sure Modula-3 even supports that, but it's one the small subtleties of dynamic linking that can trip up some unusual slightly sleazy C code)) - Jay Date: Fri, 1 Feb 2008 20:08:59 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; jayk123 at hotmail.comCC: hosking at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy>>> Jay 2/1/2008 8:02 PM >>>"I386_LINUX"? You aren't off renaming platforms now are you Tony? :)Agreed. I stopped looking when I noticed the license..Aha..I guess that is the point of the two "integrated" x86 backends?There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe.The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that...You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 03:23:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 21:23:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <3F43F984-4CF8-4F74-A422-0F129FD00707@cs.purdue.edu> Sorry: I386_DARWIN. On Feb 1, 2008, at 8:02 PM, Jay wrote: > "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) > Agreed. I stopped looking when I noticed the license.. > Aha..I guess that is the point of the two "integrated" x86 backends? > There's just one code base, there there is m3back and > m3staloneback. One builds a .lib, one builds an .exe. > The .exe probably reads the binary file and then replays the > function calls..it's marshaling layer and all that... > You can move the code around to avoid spreading the license and all > that.. > > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:56:18 -0500 > > To: jayk123 at hotmail.com > > > > It would be nice to have the x86 integrated backend for I386_LINUX > > and LINUXLIBC6 too -- just like the old PM3 did. > > > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > > > Hey, I'd kind of like that backend to stay actually. It's quite > > > fast and generates better code than unoptimized gcc and > competitive > > > code with optimized gcc. There's no AMD64 support anywhere yet in > > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > > > I don't think it is all that gnarly either. But somewhat. It's a > > > bit like code I've see that is so often handling one case after > > > another case after yet another case, yet who knows what all the > > > cases are and which order (if any particular) they should be > > > handled in? That is, it's actually kind of easier to read it and > > > understand what it does do, and realize that is "correct" in the > > > "necessary" sense, but hard to know if it is "sufficient". > > > I've got outstanding diffs for int64 support I'd like to get > back to. > > > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > > It's just a slight alteration of x86.. > > > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > > substantially better code. > > > It doesn't remember much, doesn't make multiple passes, doesn't > > > have a high level representation, etc. > > > > > > In the unlikely event that I succeed, presumably PPC would be > > > next...:) > > > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > > both in terms of platform each and optimization..and hopefully > > > build speed.) > > > > > > - Jay > > > > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > > that gnarly x86 backend will go away soon anyway -- it's > probably > > > > never going to survive in the x86_64 universe and beyond! > > > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > > > Actually it's slightly more real than I said. > > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/ > NT386MINGNU. > > > > > Sometimes it uses the "extra" code, sometimes not. These > are in a > > > > > sense a limited form of cross build. Granted, if it was > only for > > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > > > - Jay > > > > > > > > > > From: jayk123 at hotmail.com > > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > This was deliberate. It enables some cross-build scenarios. > That I > > > > > admit I haven't used (yet?), but I really like the idea. > > > > > If m3linker were completed, then "full" cross builds would be > > > real. > > > > > > > > > > The "extra" packages are small and build fast (well, at > least not > > > > > using cm3cg...). > > > > > Is it really so onerous? Really? > > > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > > Like, when you are building on non-NT386, you can easily > see that > > > > > you didn't break building on NT386, at least partly. > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > > To: hosking at elego.de > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > > > I just checked in support for full declaration of paramters > > > even on > > > > > > imported procedures in the gcc-based backend. This is to > support > > > > > > proper generation of stdcall calling convention on Windows. > > > In the > > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > > platforms now needs to build and ship both of the Windows > x86 > > > > > support > > > > > > libraries m3back and m3objfile, even though non-Windows > > > platforms > > > > > > don't use or need them. This seems broken to me. It seems > > > that cm3 > > > > > > has changed so that it now has these dependencies. Can we > please > > > > > > undo this? -- I see no need to have to build these for > non-x86 > > > > > > platforms that will never use them. > > > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > > > Modified files: > > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > > > Log message: > > > > > > > Add parameter decls even for imported procedures, as > per Jay > > > > > > > Krell's request > > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > > more. > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 07:23:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 06:23:09 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <20080204054529.A4C4F10D4611@birch.elegosoft.com> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: (and codegen..) C:\dev2\j\m3\t>type t.c typedef struct { int a,b,c,d,e,f;} Foo_t; void __stdcall Sleep(Foo_t foo); extern Foo_t a; void F1(){ Sleep(a);} C:\dev2\j\m3\t>gcc -c -S t.c C:\dev2\j\m3\t>type t.s .file "t.c" .text.globl _F1 .def _F1; .scl 2; .type 32; .endef_F1: pushl %ebp movl %esp, %ebp subl $24, %esp movl _a, %eax movl %eax, (%esp) movl _a+4, %eax movl %eax, 4(%esp) movl _a+8, %eax movl %eax, 8(%esp) movl _a+12, %eax movl %eax, 12(%esp) movl _a+16, %eax movl %eax, 16(%esp) movl _a+20, %eax movl %eax, 20(%esp) call _Sleep at 24 subl $24, %esp leave ret C:\dev2\j\m3\t>(NOTE: This is NOT the correct declaration of Sleep, but ok for testing purposes.) C:\dev2\j\m3\t>type t.i3INTERFACE T; TYPE Foo_t = RECORD a,b,c,d,e,f : INTEGER;END; <*EXTERNAL Sleep:WINAPI*>PROCEDURE Sleep (dwMilliseconds1: Foo_t); END T. C:\dev2\j\m3\t>type t.m3 MODULE T; VAR Foo: Foo_t; BEGIN Sleep(Foo);END T. LM1: movl 8(%ebp), %eax xorl $1, %eax testb %al, %al jne L2 .stabn 68,0,6,LM2-_T_M3LM2: movl $_MM_T+52, %eax movl %eax, %edx subl $8, %esp subl $24, %esp movl %esp, %eax movl %eax, %edi movl %edx, %esi cld movl $6, %eax movl %eax, %ecx rep movsl call _Sleep at 4 addl $8, %espL2: movl $_MM_T, %eaxLBE2: leal -8(%ebp), %esp popl %esi popl %edi leave ret ? - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 15:52:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 09:52:31 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: Any chance that standard_structs in Target.i3 is causing the front- end to pass structs by reference (standard structs=TRUE)? Also, looking at pop_struct in parse.c it seems to want to pass them by reference (standard_structs=FALSE)? In any case, what does the integrated back-end do with pop_struct? I bet it is passing by value... whereas parse.c passes by ref. Blurgh! Looks like we need to smarten things up for calls to non-M3 stdcall procedures. On Feb 4, 2008, at 1:23 AM, Jay wrote: > (and codegen..) > > C:\dev2\j\m3\t>type t.c > > typedef struct { > int a,b,c,d,e,f; > } Foo_t; > > void __stdcall Sleep(Foo_t foo); > > extern Foo_t a; > > void F1() > { > Sleep(a); > } > > C:\dev2\j\m3\t>gcc -c -S t.c > > C:\dev2\j\m3\t>type t.s > .file "t.c" > .text > .globl _F1 > .def _F1; .scl 2; .type 32; .endef > _F1: > pushl %ebp > movl %esp, %ebp > subl $24, %esp > movl _a, %eax > movl %eax, (%esp) > movl _a+4, %eax > movl %eax, 4(%esp) > movl _a+8, %eax > movl %eax, 8(%esp) > movl _a+12, %eax > movl %eax, 12(%esp) > movl _a+16, %eax > movl %eax, 16(%esp) > movl _a+20, %eax > movl %eax, 20(%esp) > call _Sleep at 24 > subl $24, %esp > leave > ret > C:\dev2\j\m3\t> > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > testing purposes.) > > C:\dev2\j\m3\t>type t.i3 > INTERFACE T; > > TYPE Foo_t = RECORD > a,b,c,d,e,f : INTEGER; > END; > > <*EXTERNAL Sleep:WINAPI*> > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > END T. > > C:\dev2\j\m3\t>type t.m3 > > MODULE T; > VAR > Foo: Foo_t; > > BEGIN > Sleep(Foo); > END T. > > > LM1: > movl 8(%ebp), %eax > xorl $1, %eax > testb %al, %al > jne L2 > .stabn 68,0,6,LM2-_T_M3 > LM2: > movl $_MM_T+52, %eax > movl %eax, %edx > subl $8, %esp > subl $24, %esp > movl %esp, %eax > movl %eax, %edi > movl %edx, %esi > cld > movl $6, %eax > movl %eax, %ecx > rep > movsl > call _Sleep at 4 > addl $8, %esp > L2: > movl $_MM_T, %eax > LBE2: > leal -8(%ebp), %esp > popl %esi > popl %edi > leave > ret > > ? > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 20:43:43 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:43:43 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I think they are being passed correctly, by value. pop_struct and not pop_param is used. When I get time, I will put my parse.c back (uncommited) and then just try some tests with "__cdecl" passing and returning structs. That removes the naming issue and PART of the calling convention issue and tests what is left. Then I'll see if I can hack something up to test the rest. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 20:46:00 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:46:00 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures. ps: m3 or not m3 I would think. stdcall is stdcall, independent of the implementing language. Though sure, the C declaration could declare the thing by const pointer. Given some existing unchanged C declarations for "callbacks" however, I should be able to implement them in M3. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 21:30:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:23 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> OK. Not sure I understand what is going on then -- I would like to see the .mc file to get a sense of things. On Feb 4, 2008, at 2:43 PM, Jay wrote: > I think they are being passed correctly, by value. pop_struct and > not pop_param is used. > When I get time, I will put my parse.c back (uncommited) and then > just try some tests with "__cdecl" passing and returning structs. > That removes the naming issue and PART of the calling convention > issue and tests what is left. > Then I'll see if I can hack something up to test the rest. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From hosking at cs.purdue.edu Mon Feb 4 21:30:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:59 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I don't think I follow you. On Feb 4, 2008, at 2:46 PM, Jay wrote: > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > the implementing language. > Though sure, the C declaration could declare the thing by const > pointer. > > Given some existing unchanged C declarations for "callbacks" > however, I should be able to implement them in M3. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From jayk123 at hotmail.com Mon Feb 4 21:38:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:38:28 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > > > to smarten things up for calls to non-M3 stdcall procedures. Why is the smartening specific to non-M3 procedures?I should be able to write stdcall functions in M3 as well, that take and return structs, I am so inclined or "forced". (Arguably, it should be the default. It is slightly more efficient.) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:59 -0500> To: jayk123 at hotmail.com> > I don't think I follow you.> > On Feb 4, 2008, at 2:46 PM, Jay wrote:> > > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> >> > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > the implementing language.> > Though sure, the C declaration could declare the thing by const > > pointer.> >> > Given some existing unchanged C declarations for "callbacks" > > however, I should be able to implement them in M3.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 21:51:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:51:01 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working. m3quake => sysutils => libm3/TextExtras but TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do. I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 22:01:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:01:44 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: This is without your most recent changes. > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:23 -0500> To: jayk123 at hotmail.com> > OK. Not sure I understand what is going on then -- I would like to > see the .mc file to get a sense of things.> > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > > I think they are being passed correctly, by value. pop_struct and > > not pop_param is used.> > When I get time, I will put my parse.c back (uncommited) and then > > just try some tests with "__cdecl" passing and returning structs. > > That removes the naming issue and PART of the calling convention > > issue and tests what is left.> > Then I'll see if I can hack something up to test the rest.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:05:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:05:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <927CD38A-8DA0-4963-83D4-265C9098BDCC@cs.purdue.edu> I agree. I was suspicious of the standard_structs flag -- you probably know better than I do what it is supposed to do. On Feb 4, 2008, at 3:38 PM, Jay wrote: > > > > to smarten things up for calls to non-M3 stdcall procedures. > > Why is the smartening specific to non-M3 procedures? > I should be able to write stdcall functions in M3 as well, that > take and return structs, I am so inclined or "forced". > (Arguably, it should be the default. It is slightly more efficient.) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:59 -0500 > > To: jayk123 at hotmail.com > > > > I don't think I follow you. > > > > On Feb 4, 2008, at 2:46 PM, Jay wrote: > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > > the implementing language. > > > Though sure, the C declaration could declare the thing by const > > > pointer. > > > > > > Given some existing unchanged C declarations for "callbacks" > > > however, I should be able to implement them in M3. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 4 22:09:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:09:50 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: 5.1.8 worked From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: bootstrapping from old versions?Date: Mon, 4 Feb 2008 20:51:01 +0000 It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working.m3quake => sysutils => libm3/TextExtrasbut TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do.I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 22:19:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:19:38 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: Jay, I'm not on Windows so I can't diagnose the stdcall problem. I want to see the .mc file so I can get a sense of what is going on. On Feb 4, 2008, at 4:01 PM, Jay wrote: > This is without your most recent changes. > > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > To: jayk123 at hotmail.com > > > > OK. Not sure I understand what is going on then -- I would like to > > see the .mc file to get a sense of things. > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > I think they are being passed correctly, by value. pop_struct and > > > not pop_param is used. > > > When I get time, I will put my parse.c back (uncommited) and then > > > just try some tests with "__cdecl" passing and returning structs. > > > That removes the naming issue and PART of the calling convention > > > issue and tests what is left. > > > Then I'll see if I can hack something up to test the rest. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Connect and share in new ways with Windows Live. Get it now! > From jayk123 at hotmail.com Mon Feb 4 22:28:49 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:28:49 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: understood, did the attachment not come through? attached again (parse.c changes aren't really relevant here anyway, not for the *c files, but for the *s files) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 16:19:38 -0500> To: jayk123 at hotmail.com> > Jay,> > I'm not on Windows so I can't diagnose the stdcall problem. I want > to see the .mc file so I can get a sense of what is going on.> > On Feb 4, 2008, at 4:01 PM, Jay wrote:> > > This is without your most recent changes.> >> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 15:30:23 -0500> > > To: jayk123 at hotmail.com> > >> > > OK. Not sure I understand what is going on then -- I would like to> > > see the .mc file to get a sense of things.> > >> > > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > >> > > > I think they are being passed correctly, by value. pop_struct and> > > > not pop_param is used.> > > > When I get time, I will put my parse.c back (uncommited) and then> > > > just try some tests with "__cdecl" passing and returning structs.> > > > That removes the naming issue and PART of the calling convention> > > > issue and tests what is left.> > > > Then I'll see if I can hack something up to test the rest.> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: stdcall naming discrepancy?> > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > > Any chance that standard_structs in Target.i3 is causing the > > front-> > > > > end to pass structs by reference (standard structs=TRUE)? Also,> > > > > looking at pop_struct in parse.c it seems to want to pass > > them by> > > > > reference (standard_structs=FALSE)? In any case, what does the> > > > > integrated back-end do with pop_struct? I bet it is passing by> > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > > need> > > > > to smarten things up for calls to non-M3 stdcall procedures.> > > > >> > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > > >> > > > > > (and codegen..)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.c> > > > > >> > > > > > typedef struct {> > > > > > int a,b,c,d,e,f;> > > > > > } Foo_t;> > > > > >> > > > > > void __stdcall Sleep(Foo_t foo);> > > > > >> > > > > > extern Foo_t a;> > > > > >> > > > > > void F1()> > > > > > {> > > > > > Sleep(a);> > > > > > }> > > > > >> > > > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > > > >> > > > > > C:\dev2\j\m3\t>type t.s> > > > > > .file "t.c"> > > > > > .text> > > > > > .globl _F1> > > > > > .def _F1; .scl 2; .type 32; .endef> > > > > > _F1:> > > > > > pushl %ebp> > > > > > movl %esp, %ebp> > > > > > subl $24, %esp> > > > > > movl _a, %eax> > > > > > movl %eax, (%esp)> > > > > > movl _a+4, %eax> > > > > > movl %eax, 4(%esp)> > > > > > movl _a+8, %eax> > > > > > movl %eax, 8(%esp)> > > > > > movl _a+12, %eax> > > > > > movl %eax, 12(%esp)> > > > > > movl _a+16, %eax> > > > > > movl %eax, 16(%esp)> > > > > > movl _a+20, %eax> > > > > > movl %eax, 20(%esp)> > > > > > call _Sleep at 24> > > > > > subl $24, %esp> > > > > > leave> > > > > > ret> > > > > > C:\dev2\j\m3\t>> > > > > >> > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > > for> > > > > > testing purposes.)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.i3> > > > > > INTERFACE T;> > > > > >> > > > > > TYPE Foo_t = RECORD> > > > > > a,b,c,d,e,f : INTEGER;> > > > > > END;> > > > > >> > > > > > <*EXTERNAL Sleep:WINAPI*>> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > > > END T.> > > > > >> > > > > > C:\dev2\j\m3\t>type t.m3> > > > > >> > > > > > MODULE T;> > > > > > VAR> > > > > > Foo: Foo_t;> > > > > >> > > > > > BEGIN> > > > > > Sleep(Foo);> > > > > > END T.> > > > > >> > > > > >> > > > > > LM1:> > > > > > movl 8(%ebp), %eax> > > > > > xorl $1, %eax> > > > > > testb %al, %al> > > > > > jne L2> > > > > > .stabn 68,0,6,LM2-_T_M3> > > > > > LM2:> > > > > > movl $_MM_T+52, %eax> > > > > > movl %eax, %edx> > > > > > subl $8, %esp> > > > > > subl $24, %esp> > > > > > movl %esp, %eax> > > > > > movl %eax, %edi> > > > > > movl %edx, %esi> > > > > > cld> > > > > > movl $6, %eax> > > > > > movl %eax, %ecx> > > > > > rep> > > > > > movsl> > > > > > call _Sleep at 4> > > > > > addl $8, %esp> > > > > > L2:> > > > > > movl $_MM_T, %eax> > > > > > LBE2:> > > > > > leal -8(%ebp), %esp> > > > > > popl %esi> > > > > > popl %edi> > > > > > leave> > > > > > ret> > > > > >> > > > > > ?> > > > > >> > > > > > - Jay> > > > > >> > > > > > Connect and share in new ways with Windows Live. Get it now!> > > > >> > > >> > > >> > > > Climb to the top of the charts! Play the word scramble challenge> > > > with star power. Play now!> > >> >> >> > Connect and share in new ways with Windows Live. Get it now! > > > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:59:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:59:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: I just checked in a fix that initializes void_list_node. I think this may be the fix you need for stdargs. As far as I know, void_list_node is used to mark the end of non-varargs parameter lists. On Feb 4, 2008, at 4:28 PM, Jay wrote: > understood, did the attachment not come through? > attached again > (parse.c changes aren't really relevant here anyway, not for the *c > files, but for the *s files) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 16:19:38 -0500 > > To: jayk123 at hotmail.com > > > > Jay, > > > > I'm not on Windows so I can't diagnose the stdcall problem. I want > > to see the .mc file so I can get a sense of what is going on. > > > > On Feb 4, 2008, at 4:01 PM, Jay wrote: > > > > > This is without your most recent changes. > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > OK. Not sure I understand what is going on then -- I would > like to > > > > see the .mc file to get a sense of things. > > > > > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > > > > > I think they are being passed correctly, by value. > pop_struct and > > > > > not pop_param is used. > > > > > When I get time, I will put my parse.c back (uncommited) > and then > > > > > just try some tests with "__cdecl" passing and returning > structs. > > > > > That removes the naming issue and PART of the calling > convention > > > > > issue and tests what is left. > > > > > Then I'll see if I can hack something up to test the rest. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: stdcall naming discrepancy? > > > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > > > front- > > > > > > end to pass structs by reference (standard structs=TRUE)? > Also, > > > > > > looking at pop_struct in parse.c it seems to want to pass > > > them by > > > > > > reference (standard_structs=FALSE)? In any case, what > does the > > > > > > integrated back-end do with pop_struct? I bet it is > passing by > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks > like we > > > need > > > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > > > > > (and codegen..) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > > > > > typedef struct { > > > > > > > int a,b,c,d,e,f; > > > > > > > } Foo_t; > > > > > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > > > > > extern Foo_t a; > > > > > > > > > > > > > > void F1() > > > > > > > { > > > > > > > Sleep(a); > > > > > > > } > > > > > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > > > .file "t.c" > > > > > > > .text > > > > > > > .globl _F1 > > > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > > > _F1: > > > > > > > pushl %ebp > > > > > > > movl %esp, %ebp > > > > > > > subl $24, %esp > > > > > > > movl _a, %eax > > > > > > > movl %eax, (%esp) > > > > > > > movl _a+4, %eax > > > > > > > movl %eax, 4(%esp) > > > > > > > movl _a+8, %eax > > > > > > > movl %eax, 8(%esp) > > > > > > > movl _a+12, %eax > > > > > > > movl %eax, 12(%esp) > > > > > > > movl _a+16, %eax > > > > > > > movl %eax, 16(%esp) > > > > > > > movl _a+20, %eax > > > > > > > movl %eax, 20(%esp) > > > > > > > call _Sleep at 24 > > > > > > > subl $24, %esp > > > > > > > leave > > > > > > > ret > > > > > > > C:\dev2\j\m3\t> > > > > > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, > but ok > > > for > > > > > > > testing purposes.) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > > > INTERFACE T; > > > > > > > > > > > > > > TYPE Foo_t = RECORD > > > > > > > a,b,c,d,e,f : INTEGER; > > > > > > > END; > > > > > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > > > END T. > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > > > > > MODULE T; > > > > > > > VAR > > > > > > > Foo: Foo_t; > > > > > > > > > > > > > > BEGIN > > > > > > > Sleep(Foo); > > > > > > > END T. > > > > > > > > > > > > > > > > > > > > > LM1: > > > > > > > movl 8(%ebp), %eax > > > > > > > xorl $1, %eax > > > > > > > testb %al, %al > > > > > > > jne L2 > > > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > > > LM2: > > > > > > > movl $_MM_T+52, %eax > > > > > > > movl %eax, %edx > > > > > > > subl $8, %esp > > > > > > > subl $24, %esp > > > > > > > movl %esp, %eax > > > > > > > movl %eax, %edi > > > > > > > movl %edx, %esi > > > > > > > cld > > > > > > > movl $6, %eax > > > > > > > movl %eax, %ecx > > > > > > > rep > > > > > > > movsl > > > > > > > call _Sleep at 4 > > > > > > > addl $8, %esp > > > > > > > L2: > > > > > > > movl $_MM_T, %eax > > > > > > > LBE2: > > > > > > > leal -8(%ebp), %esp > > > > > > > popl %esi > > > > > > > popl %edi > > > > > > > leave > > > > > > > ret > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it > now! > > > > > > > > > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble > challenge > > > > > with star power. Play now! > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 4 23:14:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 17:14:16 -0500 Subject: [M3devel] Latest parse.c Message-ID: See this snip from gcc/gcc/config/winnt.c: > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl)); > if (formal_type != NULL_TREE) > { > /* These attributes are ignored for variadic functions in > i386.c:ix86_return_pops_args. For compatibility with MS > compiler do not add @0 suffix here. */ > if (TREE_VALUE (tree_last (formal_type)) != void_type_node) > return DECL_ASSEMBLER_NAME (decl); We need a void_type_node there -- void_list_node now captures that properly. > /* Quit if we hit an incomplete type. Error is reported > by convert_arguments in c-typeck.c or cp/typeck.c. */ I wonder if the remaining problem with the wrong @N value is because we don't have a complete type on the formals? > while (TREE_VALUE (formal_type) != void_type_node > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > { > int parm_size > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type))); > /* Must round up to include padding. This is done the same > way as in store_one_arg. */ > parm_size = ((parm_size + PARM_BOUNDARY - 1) > / PARM_BOUNDARY * PARM_BOUNDARY); > total += parm_size; > formal_type = TREE_CHAIN (formal_type);\ > } > } From jayk123 at hotmail.com Mon Feb 4 23:25:52 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 22:25:52 +0000 Subject: [M3devel] Latest parse.c In-Reply-To: References: Message-ID: I'll try later. I tried stepping through some of this in gdb but couldn't make much sense of the data. Perhaps due to optimization. And I read some of it, but didn't really notice what you point out, thanks. I need to be more willing to resort to printf debugging..it worked well with those aligned doubles.. It should help (any of us) to use that small repro I provided. I don't think it "quits" for us, but worth the printf'ing and such. It does append "@4" to Sleep. Another thing would be try: like Sleep(int,record,int,record); I wouldn't be surprised if you get @16, but I'm placing no bets here. :) I should also try building some cross m3cg's so I can nag you to do the same. :) (if it only it were that easy, also need cross gcc, ld, headers, libs, and then could build all distributions from one machine, albeit NT386 is the real laggard here...) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Latest parse.c> Date: Mon, 4 Feb 2008 17:14:16 -0500> To: jayk123 at hotmail.com> > See this snip from gcc/gcc/config/winnt.c:> > > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl));> > if (formal_type != NULL_TREE)> > {> > /* These attributes are ignored for variadic functions in> > i386.c:ix86_return_pops_args. For compatibility with MS> > compiler do not add @0 suffix here. */> > if (TREE_VALUE (tree_last (formal_type)) != void_type_node)> > return DECL_ASSEMBLER_NAME (decl);> > We need a void_type_node there -- void_list_node now captures that > properly.> > > /* Quit if we hit an incomplete type. Error is reported> > by convert_arguments in c-typeck.c or cp/typeck.c. */> > I wonder if the remaining problem with the wrong @N value is because > we don't have a complete type on the formals?> > > while (TREE_VALUE (formal_type) != void_type_node> > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > > {> > int parm_size> > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type)));> > /* Must round up to include padding. This is done the same> > way as in store_one_arg. */> > parm_size = ((parm_size + PARM_BOUNDARY - 1)> > / PARM_BOUNDARY * PARM_BOUNDARY);> > total += parm_size;> > formal_type = TREE_CHAIN (formal_type);\> > }> > }> > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 5 10:36:55 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 5 Feb 2008 09:36:55 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801291036.m0TAaVws062299@camembert.async.caltech.edu> References: Your message of "Mon, 28 Jan 2008 12:38:38 GMT." <200801291036.m0TAaVws062299@camembert.async.caltech.edu> Message-ID: Mika you are right, e.g.: C:\pm3\bin>mentor.exe ****** runtime error:*** ThreadWin32.m3, line 726: Windows OS failure, GetLastError = 8*** use option @M3stackdump to get a stack trace 20754 [unknown (0xF84)] mentor 2780 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 42083 [unknown (0xF84)] mentor 2780 open_stackdumpfile: Dumping stack trace to mentor.exe.stackdump And it uses Win32 gui. I am still inclined to use pthreads though.. - Jay > To: jayk123 at hotmail.com> Subject: Re: [M3devel] nt386gnu threads? > Date: Tue, 29 Jan 2008 02:36:31 -0800> From: mika at async.caltech.edu> > > Sorry, I don't have the m3makefiles. I just have a binary installation> of PM3/Klagenfurt.> > Practice your German:> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > here...> > http://www.1o0.de/wi-links/modula3/> > (Sorry I don't even have access to my Windows system right now.)> > Mika> > Jay writes:> >--_14fad708-4bac-4aaf-ab93-c9649038a920_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Um, so the file exists..does it get compiled? Did you look at the m3makefil=> >es?> >I skimmed the m3makefiles. I have not tried building PM3 myself.> >=20> > - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Feb 5 12:15:44 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 5 Feb 2008 12:15:44 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Message-ID: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Hi Olaf: Is still possible to add Literate programming support, I mean using several functions that are just a commentary at the end of the file on M3Build.m3: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain Also there is a missing one on Built-in functions, one that "copy" the derived source of a noweb file (specifically a generic) from the Target (e.g LINUXLIBC6) directory of the compiler to the src directory. In that way the compiler can use the source. The name of functions could be: "derived_generic_interface", "derived_generic_implementation" This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ The literate programming support was present on DEC SRC M3 I think: http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Thanks Daniel Benavides Olaf Wagner escribi?: Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 5 12:39:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 05 Feb 2008 12:39:23 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080205123923.qvlr4noeocgkc8gs@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain You're talking of the builder's built-in functions; I haven't had a close look at them yet (just extended the pure quake built-ins). Of course it should be possible to add support for literate programming; but I haven't any experience with this. > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. I don't think it should be done this way, and it wouldn't really work, as the compiler would need two passes for each package then; all derived files should be kept in the TARGET directory. I think derived sources for literate programming should be handled in the same way as instantiated generics (e.g. based on quake templates). > In that way the compiler can use the source. The name of functions > could be: "derived_generic_interface", > "derived_generic_implementation" The actual implementation could be done in quake first and maybe later be implemented in M3 in the builder for performance reasons. > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html As I said, I've never used it and don't know about it, but will have a look at it when I've got some time. If you could provide some of the needed quake functions, that would of course 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 Wed Feb 6 20:15:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 06 Feb 2008 20:15:26 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 6 22:46:31 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 6 Feb 2008 21:46:31 +0000 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: Modula-3 and quake both support writing comments already. :) I guess a "cross referencing" scheme would be nice, but to some extent that should be automatic. To some extent, or entirely, it is what Reactor is. All the calls to a function or references to a type are immediately findable, I think. All you really need is a) a completely global namespace so every identifier is unique b) plain text search based on an index. I like C++ and I like some about Modula-3, but hierarchical namespaces really stink in the face of (indexed) plain text search, and no other kind of search can keep up with large codebases. How do I find uses of this particular "T" when people can and do make aliases? I realize C has typedefs to establish aliases, and nesting, so that argument is somewhat moot (the point is more relevant for C++, trying to make it Modula-3-relevant). In C++, how do I search for calls to a particular operator=? Or to a constructor? I'm just being obnoxious. ...Jay > Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dabenavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." :> > > Hi Olaf:> > Is still possible to add Literate programming support, I mean using > > several functions that are just a commentary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain> >> > Also there is a missing one on Built-in functions, one that "copy" > > the derived source of a noweb file (specifically a generic) from the > > Target (e.g LINUXLIBC6) directory of the compiler to the src > > directory. In that way the compiler can use the source. The name of > > functions could be: "derived_generic_interface", > > "derived_generic_implementation"> >> > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/> > The literate programming support was present on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a look at all that stuff, even downloaded ldb and installed noweb.> Still, I'd need a simple example to understand what exactly you would> like to have included in CM3 by default. Just the four commented-out> noweb procedures from M3Build.m3? Or more elaborate stuff like that> included in the ldb distribution?> > Is there any problem with just including the 4 quake procedures as> template? Anything that would not work?> > If you could provide a simple m3 package which contains all the uses> you'd like to see supported, we could even use that as a regression> test add-on. So if you send me a more specific and exact definition> and example, I'll try to add everything that is needed.> > I've never done literate programming myself, and haven't got the time> to learn everything now and decide what is needed.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Feb 6 23:04:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 06 Feb 2008 14:04:43 -0800 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: Your message of "Wed, 06 Feb 2008 21:46:31 GMT." Message-ID: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Isn't Nelson's book "Systems Programming with Modula-3" to a large extent composed of literate programming (Threads interfaces, etc.)? Modula-3 has really cool literate programming support and it'd be a shame to lose it. Also m3browser does support the automatic cross referencing you're talking about. Last I checked it was a bit buggy. In my experience, one of the really nice things about Modula-3 when you write moderately large programs is actually that it's very easy to find out where a T is being used, without using any special tools (like m3browser). You just grep for the name of the interface where that T is defined, and that gives you a superset of all possible uses of T. Modula-3 doesn't have the nasty Javaism "import libm3.*;" Mika Jay writes: >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Modula-3 and quake both support writing comments already. :) >=20 >I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic. >To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think. >=20 >All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index. >=20 >I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor? >=20 >I'm just being obnoxious. >=20 > ...Jay > > > >> Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dab= >enavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake= > extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." enavidesd at yahoo.es>:> > > Hi Olaf:> > Is still possible to add Literate pro= >gramming support, I mean using > > several functions that are just a commen= >tary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.= >com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=3D1.8;c= >ontent-type=3Dtext%2Fplain> >> > Also there is a missing one on Built-in fu= >nctions, one that "copy" > > the derived source of a noweb file (specifical= >ly a generic) from the > > Target (e.g LINUXLIBC6) directory of the compile= >r to the src > > directory. In that way the compiler can use the source. Th= >e name of > > functions could be: "derived_generic_interface", > > "derived= >_generic_implementation"> >> > This stuff is used on ldb debugger : http://= >www.eecs.harvard.edu/nr/ldb/> > The literate programming support was presen= >t on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS= >/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a = >look at all that stuff, even downloaded ldb and installed noweb.> Still, I'= >d need a simple example to understand what exactly you would> like to have = >included in CM3 by default. Just the four commented-out> noweb procedures f= >rom M3Build.m3? Or more elaborate stuff like that> included in the ldb dist= >ribution?> > Is there any problem with just including the 4 quake procedure= >s as> template? Anything that would not work?> > If you could provide a sim= >ple m3 package which contains all the uses> you'd like to see supported, we= > could even use that as a regression> test add-on. So if you send me a more= > specific and exact definition> and example, I'll try to add everything tha= >t is needed.> > I've never done literate programming myself, and haven't go= >t the time> to learn everything now and decide what is needed.> > Olaf> -- = >> Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb= >=E4ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177= > 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf= >=FChrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlotten= >burg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Modula-3 and quake both support writing comments = >already. :)
> 
>I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic.
>To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think.
> 
>All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index.
> 
>I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor?
> 
>I'm just being obnoxious.
> 
> ...Jay


> >
>
>> Date: Wed, 6 Feb 2008 20:15:26 +0100
> From: wagner at elegosoft.co= >m
> To: dabenavidesd at yahoo.es
> CC: m3devel at elegosoft.com
&g= >t; Subject: Re: [M3devel] quake extensions for tests / RFC
>
>= > Quoting "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>:
= >>
> > Hi Olaf:
> > Is still possible to add Literate = >programming support, I mean using
> > several functions that are = >just a commentary at the end of the file
> > on M3Build.m3:
&g= >t; > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-s= >ys/cm3/src/M3Build.m3?rev=3D1.8;content-type=3Dtext%2Fplain
> >>> > Also there is a missing one on Built-in functions, one that "cop= >y"
> > the derived source of a noweb file (specifically a generic= >) from the
> > Target (e.g LINUXLIBC6) directory of the compiler = >to the src
> > directory. In that way the compiler can use the so= >urce. The name of
> > functions could be: "derived_generic_interf= >ace",
> > "derived_generic_implementation"
> >
> &= >gt; This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb= >/
> > The literate programming support was present on DEC SRC M3 I= > think:
> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA= >_3/html/modula-3/html/m3build/noweb.html
>
> Hi again,
>= >
> I've had a look at all that stuff, even downloaded ldb and instal= >led noweb.
> Still, I'd need a simple example to understand what exac= >tly you would
> like to have included in CM3 by default. Just the fou= >r commented-out
> noweb procedures from M3Build.m3? Or more elaborate= > stuff like that
> included in the ldb distribution?
>
>= > Is there any problem with just including the 4 quake procedures as
>= > template? Anything that would not work?
>
> If you could prov= >ide a simple m3 package which contains all the uses
> you'd like to s= >ee supported, we could even use that as a regression
> test add-on. S= >o if you send me a more specific and exact definition
> and example, = >I'll try to add everything that is needed.
>
> I've never done= > literate programming myself, and haven't got the time
> to learn eve= >rything now and decide what is needed.
>
> Olaf
> -- >> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-All= >ee 25 / Geb=E4ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 = >96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.eleg= >osoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelr= >egister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
&g= >t;


Connect and share in new ways with Windows Live. href=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharel= >ife_012008' target=3D'_new'>Get it now! >= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_-- From wagner at elegosoft.com Thu Feb 7 00:07:08 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 07 Feb 2008 00:07:08 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> References: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Message-ID: <20080207000708.380w844gg80cws0k@mail.elegosoft.com> Quoting Mika Nystrom : > Isn't Nelson's book "Systems Programming with Modula-3" to a large > extent composed of literate programming (Threads interfaces, etc.)? > Modula-3 has really cool literate programming support and it'd be > a shame to lose it. Also m3browser does support the automatic cross > referencing you're talking about. Last I checked it was a bit > buggy. Well, I think you're right and one can see m3browser as a kind of special literate programming support. And if it is currently buggy -- perhaps you could explain what exactly is wrong -- we should certainly fix it. However, I understood the request of Daniel Alejandro Benavides as one to re-add support for some generic literate programming tools which where already supported in earlier releases of M3. There is no harm in that, and I think we should be open for integrations of many such tools. I don't think it will be very difficult to add this support (as it has already been there), I'm just not familiar enough with the noweb tools to exactly know what is needed, so I asked for some help. I also think the SGML tools that were used for the PM3 documentation are a kind of literate programming support; and that's probably the most powerful and promising solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Feb 7 03:30:49 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 Feb 2008 03:30:49 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Feb 8 21:49:19 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 8 Feb 2008 21:49:19 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Message-ID: <32680.74034.qm@web27114.mail.ukl.yahoo.com> Hi: I'm sorry for not writing you all the things I like to see on CM3. It seems that the creator of ldb (Norman Ramsey) has been the creator of noweb, so I think his package as far as I have compiled it, is a good test, but maybe too large, so yes I would love to contribute with it. >Is there any problem with just including the 4 quake procedures as >template? Anything that would not work? There isn`t (I think I have compiled with those functions as a ldb-template package template on ldb), but the builtin procedure which I don't see is the one I wrote so I think it should be added in this text case of ldb but also in other cases (I think quake acts as a prepocessor of the noweb Modula-3/generic sources). Thanks again, and hope that I answeres better this time. "Daniel Alejandro Benavides D." escribi?: Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 9 18:52:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 09 Feb 2008 18:52:43 +0100 Subject: [M3devel] www.opencm3.net, m3tohtml and current CM3 source browser Message-ID: <20080209185243.kbm6grheyoks40g0@mail.elegosoft.com> After looking for some suitable domain names that are still available, Elego has secured www.opencm3.net to allow easier access to the CM3 project. http://www.opemcm3.net is now the same as http://modula3.elegosoft.com/cm3/ but shorter and probably easier to remember. Unfortunately www.opencm3.org and the shorter www.cm3.xxx domains are already owned by others. I've made a small update to m3tohtml and automated the HTML doc generation in cm3/scripts/regression/defs.sh:test_m3tohtml. This is now also run nightly on birch.elegosoft.com. Next to running m3browser directly on our web server, this seems the easiest way to allow browsing of all current sources. Have a look at http://www.opencm3.net/doc/help/gen_html/INDEX.html. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 10 10:28:22 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:28:22 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: "cross posting", guilty. (This might have something to do with NT386GNU CM3 hanging upon startup but I haven't figured out much..in CM3, nanosleep fails and I don't think ThreadPThread__SignalHandler is ever called, whereas here nanosleep succeeds and the signal handler is called at least a few times; I'm going to try some hack with the Cygwin nanosleep uses sleep instead or something...) From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 10 10:43:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:43:58 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: oh the burden of my own cross-posting.. - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: RE: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:43:20 +0000 Given that sleep is implemented via nanosleep in the obvious simple way..Still, any additional clues/explanations are welcome. :) - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sun Feb 10 22:55:01 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 10 Feb 2008 15:55:01 -0600 Subject: [M3devel] <*LAZYALIGN*> Message-ID: <47AF72B5.2080308@wichita.edu> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it being used anywhere? It is not documented in pragmas.html. The compiler front end appears to accept it. (In fact, Decls.m3 contains constants that suggest limitations on what declarations the pragma can appear on, but these are not actually enforced.) It liberalizes the alignment rules, generally allowing scalars to start on any byte boundary. Pickles have to be able to reconstruct the layout of types as the compiler would have done it for a machine (on which a now-being-read pickle was written) with different word size and alignment properties. Currently, pickles are completely unaware of lazy alignment. It would have to be encoded in type descriptions generated by the compiler using TipeDesc and read by pickles using RTTipe. Most troubling to me is what looks like a linguistic Pandora's box. The pragma can be associated with any constant, variable, or type _declaration_ (not type definition), with the result that different values of the same type can actually be different in their alignment rules and thus their layout. Similarly for different identifiers equated to the same type. Although the effects of this could possibly be hidden from the programmer in purely safe code, not so with unsafe code. I haven't thoroughly thought this through, but seems to me to really fly in the face of the whole typing philosophy of the language. For example, if pickles were to read in an object value, and there were >1 variants of the object's type in the reading program, differing only in the alignment rules, how would it decide which one to build? In fact, ignoring pickles altogether and just looking at a single program, if the object's type doesn't actually uniquely give its memory layout, how can it be accessed correctly? Additionally, a quick look at the compiler suggests it won't generate correct code for whole record assignment when the LHS and RHS are the same type but have different alignment characteristics. The more I think about it, it seems the only workable possibilities are: 1) Require the pragma to be associated only with a type _definition_ not a declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make this a property of the type that propagates to all names for the type and all variables, constants, etc. Also, this would make this property a part of the type signature that pickles uses when reading, -OR- 2) Forget it altogether. What do people think? -- ------------------------------------------------------------- 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 Mon Feb 11 10:15:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: <20080211091341.D290C10D4527@birch.elegosoft.com> References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:29:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:29:10 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080211092401.1068410D466B@birch.elegosoft.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: Does anyone else find it bothersome that you can't introduce VARs anywhere? Kind of like in C++? Ok, or if you grant that frame size doesn't matter THAT much, and the compiler might do stack packing anyway, you can move all your locals up top like typical C, but still, how about for the module initializer? Still it seems good to me to do manual stack packing since it is often so easy.. WITH helps, but only for "relative constants". It would be nice if the code below could have still loops until t0 != t1, but the repeat condition is outside the scope in which t1 is available. This feels quite lame.. - Jay > Date: Mon, 11 Feb 2008 10:24:00 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:24:00> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > Log message:> no need for globals here..> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:35:16 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:35:16 +0000 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 11 Feb 2008 09:15:50 +0000Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) )(Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 11 10:58:18 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 11 Feb 2008 01:58:18 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Mon, 11 Feb 2008 09:29:10 GMT." Message-ID: <200802110958.m1B9wJ9u035766@camembert.async.caltech.edu> Jay writes: >--_568f4bdf-b056-453b-9c29-b8dff8a8bb4c_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Does anyone else find it bothersome that you can't introduce VARs anywhere?= > Kind of like in C++? No. From jayk123 at hotmail.com Mon Feb 11 11:13:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:13:09 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? Message-ID: I know this won't be popular but... over in m3-db\odbc\src, there is POSIX and WIN32, and they are ALMOST identical. The differences are the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. In Win32 all the <*external*> pragmas have WINAPI. In Posix, they lack it. For this and other reasons, I suggest that all CM3 frontends accept but silentlyignore the Win32/x86 calling conventions in <*external*> pragmas,similar to what the non-x86 Windows compilers do. The other reasons would be the "FARPROC" warning that I already cleared up otherwise. And anything else minor that comes up. I know this won't be popular but I REALLY REALLY REALLY believe is the right thing.It is a small safe change that will allow a little more Modula-3 source portability. A similar suggestion would be to change the default calling convention in Modula-3,it would very possibly reduce code size, but is very very very much a breakingchange so probably can never happen.Better probably would be to a) add a switch for this b) extend the .m3exportsor whatnot files to indicate what switch was used. A "blanket pragma" might also be good, so that the various *.i3 files cansay just to assume __stdcall for the rest of the file instead of annotating each functions. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 11:20:59 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 11:20:59 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <1202725259.8543.22.camel@faramir.m3w.org> Why would we, when in M3 we can have blocks as statements? Isn't that a mechanism to localize scope even more? d On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and the > compiler might do stack packing anyway, you can move all your locals > up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is often > so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 != > t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > ______________________________________________________________________ > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > > ______________________________________________________________________ > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 11:34:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:34:19 +0000 Subject: [M3devel] __declspec(dllimport)? Message-ID: __declspec(dllimport) is a nice little cheap optimization on Windows. When you are calling a function that you will be dynamically linking to, it saves one instructions per call. On Windows, the way dynamic linking works is that for all your imports, there is one array of pointers in your .dll/.exe. It could actually be discontiguous. It is an array per .dll rather, with a terminal NULL for each .dll you import from. All the dynamic loader does is write pointers into this array at load time. It does not have to, like, go all through your code patching stuff up. If you just call Foo, but end up importing Foo, the linker generates a one instruction function: Foo: jmp dword ptr[__imp__Foo] __imp__Foo is in that array that gets patched up. However if you declare Foo to be __declspec(dllimport), the compiler will instead of: call Foo generate: call dword ptr[__imp__Foo] in fact, if you have multiple nearby calls to Foo, the compiler knows these pointers are "relatively const" and will fetch the pointer and hold it in a register and make the calls through the register. There is a problem with __declspec(dllimport). Essentially, you know, for every imported function Foo, there is somewhere out there someone implementing it. They are not importing it. They are exporting it. While getting this declaration wrong is actually "ok", it ends up costing the implementer an extra instruction on their calls, and generates a linker warning ("importing local function"). So what ends up happening usually is either a) the implementer doesn't #include his own header files, generally a bad bad bad idea or b) for every .dll bar.dll, a macro is made up BARAPI and then the code usually goes like: #ifndef BARAPI #define BARAPI __declspec(dllimport) #endif BARAPI void __stdcall Foo(void); and the implementer will define BARAPI to either be nothing/empty, or __declspec(dllexport). (__declspec(dllexport) is another topic, I'll try not to go into here.) This is a little gross, this proliferation of "cover" macros for __declspec(dllimport). But it IS a nice little optimization. Actually I suspect many people think these annotations are required. But they almost never ever are. But they are nice to have. So, what do people think? Worth some syntax? In <*extern*> pragmas? Gcc already understand this stuff I believe. I think I noticed it when looking at the __stdcall stuff. Another wrinkle here is that Modula-3 has this nice build_standalone() feature, which switches whether or not you dynamically link. It would tend to invalidate statements here, at least about Modula-3 code. On the matter of when __declspec(dllimport) is needed. - I'm not sure about C++ classes. You should just never import then really, but use COM instead, but people do. (COM is just using pure virtual function calls -- ie: calls through structs containing all function pointers, and get a pointer to said struct via a special C creation function). - It is needed for data, at least with Microsoft tools. The GNU tools seem to have some workaround here. Notice I pointed out the linker generates a function for you if you don't make the annotation. You can't intervene on data accesses with a function call, unless, say, you've inserted a function call for every single data access, or if you can still go back and change the code, like at link time. Data imports are rare and I suggest just never use them. But they are much faster when they suffice, true. __declspec(dllexport) can generally just be replaced with a .def file. - again, I don't know about C++ classes - for C++ functions, the .def file will contain some ugly processor-specific mangled names, a little bit difficult/annoying to come up with and put in the .def file, but not impossible by far (link /dump /symbols | findstr /v UNDEF for example) - again, just don't export C++ classes, or mangled/overloaded/etc. names, only export C functions and you are set with a .def file; this also aids compatibility with multiple compilers and languages (!) - (C++ is largely well and good and I can tell you what is good about it, but one thing it is NOT good for is defining dynamically linked interfaces; I think Modula-3 can get into the same trap -- e.g. traffic only in a few base types (integer, text) and opaque types, don't let dynamically linked callers know about your record format/offsets, else you'll have to recompile "too often") __declspec(dllexport) provides no optimization analogous to __declspec(dllimport). - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 11:36:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:36:19 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: Could be my ignorance of Modula-3 then..let me try a bit more.. - Jay > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 11:20:59 +0100> > Why would we, when in M3 we can have blocks as statements? Isn't that a> mechanism to localize scope even more?> > d> > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > Does anyone else find it bothersome that you can't introduce VARs> > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and the> > compiler might do stack packing anyway, you can move all your locals> > up top like typical C, but still, how about for the module> > initializer?> > Still it seems good to me to do manual stack packing since it is often> > so easy..> > WITH helps, but only for "relative constants".> > > > It would be nice if the code below could have still loops until t0 !=> > t1, but the repeat condition is outside the scope in which t1 is> > available. This feels quite lame..> > > > - Jay> > > > > > > > ______________________________________________________________________> > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > > > > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message:> > > no need for globals here..> > > > > > > > > > > ______________________________________________________________________> > Helping your favorite cause is as easy as instant messaging. You IM,> > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 12:04:09 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 12:04:09 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <1202727849.8543.24.camel@faramir.m3w.org> A piece of code, from the middle of somewhere... len:=Wr.Length(swr.wr); data := TextWr.ToText(swr.wr); VAR s: Ctypes.char_star := M3toC.CopyTtoS(data); ff: ADDRESS := LOOPHOLE(s, ADDRESS); a: UNTRACED REF CHAR; spent: CARDINAL := 0; checkSum: Word.T := 0; BEGIN a := ff; WITH sum = NEW(Sumator) DO sum.reset(); > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote: > Why would we, when in M3 we can have blocks as statements? Isn't that a > mechanism to localize scope even more? > > d > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++? > > Ok, or if you grant that frame size doesn't matter THAT much, and the > > compiler might do stack packing anyway, you can move all your locals > > up top like typical C, but still, how about for the module > > initializer? > > Still it seems good to me to do manual stack packing since it is often > > so easy.. > > WITH helps, but only for "relative constants". > > > > It would be nice if the code below could have still loops until t0 != > > t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame.. > > > > - Jay > > > > > > > > ______________________________________________________________________ > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > To: m3commit at elegosoft.com > > > From: jkrell at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message: > > > no need for globals here.. > > > > > > > > > > > ______________________________________________________________________ > > Helping your favorite cause is as easy as instant messaging. You IM, > > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 12:23:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:23:18 +0000 Subject: [M3devel] size_t? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = INTEGER; really? it is signed? and we are sure this is going to be 64 bits on 64 bit targets? size_t and ptrdiff_t ought to be in BasicCtypes, right?That has a 32 bit and 64 bit version, at least. Does INTEGER effectively equal int or ptrdiff_t? - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 12:28:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:28:01 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202727849.8543.24.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <1202727849.8543.24.camel@faramir.m3w.org> Message-ID: ok thanks, done > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 12:04:09 +0100> > A piece of code, from the middle of somewhere...> > len:=Wr.Length(swr.wr);> data := TextWr.ToText(swr.wr);> VAR> s: Ctypes.char_star := M3toC.CopyTtoS(data);> ff: ADDRESS := LOOPHOLE(s, ADDRESS);> a: UNTRACED REF CHAR;> > spent: CARDINAL := 0;> checkSum: Word.T := 0;> BEGIN> a := ff;> WITH sum = NEW(Sumator) DO> sum.reset();> > > > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote:> > Why would we, when in M3 we can have blocks as statements? Isn't that a> > mechanism to localize scope even more?> > > > d> > > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs> > > anywhere? Kind of like in C++?> > > Ok, or if you grant that frame size doesn't matter THAT much, and the> > > compiler might do stack packing anyway, you can move all your locals> > > up top like typical C, but still, how about for the module> > > initializer?> > > Still it seems good to me to do manual stack packing since it is often> > > so easy..> > > WITH helps, but only for "relative constants".> > > > > > It would be nice if the code below could have still loops until t0 !=> > > t1, but the repeat condition is outside the scope in which t1 is> > > available. This feels quite lame..> > > > > > - Jay> > > > > > > > > > > > ______________________________________________________________________> > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > > To: m3commit at elegosoft.com> > > > From: jkrell at elego.de> > > > Subject: [M3commit] CVS Update: cm3> > > > > > > > CVSROOT: /usr/cvs> > > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > > > Modified files:> > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message:> > > > no need for globals here..> > > > > > > > > > > > > > > > ______________________________________________________________________> > > Helping your favorite cause is as easy as instant messaging. You IM,> > > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 12:30:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 12:30:37 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Quoting Jay : > I know this won't be popular but... > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > The differences are > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > For this and other reasons, I suggest that all CM3 frontends accept > but silentlyignore the Win32/x86 calling conventions in <*external*> > pragmas,similar to what the non-x86 Windows compilers do. > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing.It is a small safe change that will allow a little > more Modula-3 source portability. If I understand you correctly, you'd like to declare the external procedures as WINAPI in general and let all backends except the Windows one ignore it. We should not call it WINAPI then, I think; what about SYSAPI as a general abstraction? > A similar suggestion would be to change the default calling > convention in Modula-3,it would very possibly reduce code size, but > is very very very much a breakingchange so probably can never > happen.Better probably would be to a) add a switch for this b) > extend the .m3exportsor whatnot files to indicate what switch was > used. We shouldn't change the default calling conventions. That is, we should check very very carefully if there are negative effects of doing this and how we cope with them. Until this has been done, we shouldn't change the default calling conventions :-) > A "blanket pragma" might also be good, so that the various *.i3 > files cansay just to assume __stdcall for the rest of the file > instead of annotating each functions. You're talking about a pragma default for all declarations in a file, aren't you? I wouldn't object to that, but it would probably need some compiler extensions, wouldn't 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 Mon Feb 11 13:41:39 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:41:39 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: Olaf, yes you understand me. I strongly object to calling it SYSAPI however, or pretty much any attempt at further abstraction here. I would consider some sort of qualifier that says when to pay attention, when to ignore. For example using a platform name, <*external NT386:WINAPI*>. This is edging toward "preprocessing" but an incredibly small step. (Even though a big problem with preprocessing is rampant context sensitivity, sensitivity to what the target is, and reparsing for every target, is reasonable, and is how M3 already works.) It isn't the "system" calling convention really, it is just very commonly used by the "OS". The "OS" is just a bunch of .dlls, and many of them happen to use __stdcall aka WINAPI a lot, but not all, and not for all functions. "system" MIGHT be how you call the kernel, but that is different. (calling the kernel is not directly exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). msvcrt.dll uses __cdecl for the most part. Anything that accepts varargs, which is very few functions, uses __cdecl, out of necessity (at least give a "normal" point of view, I did used to use a system where calleee popped varargs...). If you write drivers, a small number of functions are __fastcall. I would rather drop the synonyms and just have __cdecl, __fastcall, __stdcall, than to invent "SYSAPI". However I don't really want to do that, "WINAPI" and the other names are useful for a more literal translation of headers. There is a mix of calling conventions on x86 Windows and there is not really one "SYSAPI". The negative affects of changing the default calling convention is breaking all existing dynamic links where you only rebuild one side and where the calling convention wasn't explicit (all of them). Very very bad. > you'd like to declare the external procedures as WINAPI in general Not quite in general perhaps. But I guess any file for which someone has portable C and it is built for NT386 and anything else. Explicit calling conventions are always reasonable on NT386 and never reasonable anywhere else. The Visual C++ compiler has a command line switch as to what the default calling convention is, and widely used headers should work no matter what is the default. - Jay > Date: Mon, 11 Feb 2008 12:30:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > > I know this won't be popular but...> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> > The differences are> > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed.> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> > For this and other reasons, I suggest that all CM3 frontends accept > > but silentlyignore the Win32/x86 calling conventions in <*external*> > > pragmas,similar to what the non-x86 Windows compilers do.> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.It is a small safe change that will allow a little > > more Modula-3 source portability.> > If I understand you correctly, you'd like to declare the external> procedures as WINAPI in general and let all backends except the> Windows one ignore it. We should not call it WINAPI then, I think;> what about SYSAPI as a general abstraction?> > > A similar suggestion would be to change the default calling > > convention in Modula-3,it would very possibly reduce code size, but > > is very very very much a breakingchange so probably can never > > happen.Better probably would be to a) add a switch for this b) > > extend the .m3exportsor whatnot files to indicate what switch was > > used.> > We shouldn't change the default calling conventions. That is, we should> check very very carefully if there are negative effects of doing this> and how we cope with them.> Until this has been done, we shouldn't change the default calling> conventions :-)> > > A "blanket pragma" might also be good, so that the various *.i3 > > files cansay just to assume __stdcall for the rest of the file > > instead of annotating each functions.> > You're talking about a pragma default for all declarations in a> file, aren't you? I wouldn't object to that, but it would> probably need some compiler extensions, wouldn't 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> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 13:48:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:48:23 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211111256.22C8E10D4628@birch.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: Here is another SMALL gripe with the language. The need to put IMPORTS at the top (or is it just common style?), leads to something I have seen several times. You comment out some code, thereby deleting the only/last use of some import, that nets you warnings about unused imports. Granted, they are "only" warnings, but I try to have none. Also granted, you can either comment out or just go ahead and remove the imports, easy. It might be nice if the IMPORTS could be adjacent to the code using the IMPORTS, so that they can be comment out or removed together. This "problem" is not unique to Modula-3, by far. In fact, Modula-3 is probably more able to warn about this low cost waste due to its much better module system, compared to say, C and C++ #includes... - Jay > Date: Mon, 11 Feb 2008 12:12:56 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 12:12:56> > Modified files:> cm3/m3-ui/ui/src/winvbt/: WinScreenType.m3 > > Log message:> fix warning about unused import (the use is commented out..would be nice> to be able to move the import to near the code so they can be commented> out together..)> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 14:12:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:12:03 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Quoting Jay : > Olaf, yes you understand me. > > I strongly object to calling it SYSAPI however, or pretty much any > attempt at further abstraction here. > > I would consider some sort of qualifier that says when to pay > attention, when to ignore. > For example using a platform name, <*external NT386:WINAPI*>. > This is edging toward "preprocessing" but an incredibly small step. > (Even though a big problem with preprocessing is rampant context > sensitivity, sensitivity to what the target is, and reparsing for > every target, is reasonable, and is how M3 already works.) > > It isn't the "system" calling convention really, it is just very > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > many of them happen to use __stdcall aka WINAPI a lot, but not all, > and not for all functions. "system" MIGHT be how you call the > kernel, but that is different. (calling the kernel is not directly > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). OK, so it's not system specific, but its system specific that there are multiple calling conventions for Windows. However, I'm still not convinced that this may affect only Windows systems and no others. It may sound academic, but wouldn't it be possible that suddenly Apple (or even some new OS player :) comes up with similar distinctions? I think we shouldn't implement a pragma convention that is usable only for Windows, but one that is more generic. If we can just extend your example to something like <*EXTERNAL NT386:WINAPI, ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> this would be better. As for the semantic differences on different target platforms, I think we could live with them given that all this stuff is system dependent and unsafe anyway, but I'd like to hear the opinion of others on this topic, too. Olaf > msvcrt.dll uses __cdecl for the most part. > Anything that accepts varargs, which is very few functions, uses > __cdecl, out of necessity (at least give a "normal" point of view, I > did used to use a system where calleee popped varargs...). > If you write drivers, a small number of functions are __fastcall. > I would rather drop the synonyms and just have __cdecl, __fastcall, > __stdcall, than to invent "SYSAPI". > However I don't really want to do that, "WINAPI" and the other names > are useful for a more literal translation of headers. > There is a mix of calling conventions on x86 Windows and there is > not really one "SYSAPI". > > The negative affects of changing the default calling convention is > breaking all existing dynamic links where you only rebuild one side > and where the calling convention wasn't explicit (all of them). Very > very bad. > > > you'd like to declare the external procedures as WINAPI in general > > Not quite in general perhaps. > But I guess any file for which someone has portable C and it is > built for NT386 and anything else. > Explicit calling conventions are always reasonable on NT386 and > never reasonable anywhere else. > The Visual C++ compiler has a command line switch as to what the > default calling convention is, and widely used headers should work > no matter what is the default. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 11 14:17:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:17:56 +0100 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Quoting Jay : > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and > C++ #includes.. I wouldn't like to see any changes here. It is good that all the imports are explicit, and it is good that they are at the top (to define the dependencies). It's not much effort to add or remove an import for debugging etc. If you are really lazy, you can always use the NOWARN pragma: IMPOPRT IO <*NOWARN*> to suppres the warnings for that declaration. That was not your point though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Feb 11 14:31:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:31:41 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: I don't think anyone else will commit the error of having multiple calling conventions. It's a bad place to be. Granted, kernels often do have an unusual calling convention, but that gets wrapped up in something "normal". > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> In practice this will only ever be: > <*EXTERNAL NT386:WINAPI *> and I am satisfied. :) oh, btw, the other obvious: > <*NT386:EXTERNAL WINAPI *> or even in general both -- pragms can all be prefixed with a platform. In practise, "external" is platform-independent, calling convention is not. There might be exceptions, where particular platforms require a Modula-3 wrapper. As Cygwin had briefly for semaphore initialization. I guess this really does in general resemble preprocessing, only by target, only of pragmas, and the point really is to limit per-platform branching when the platforms are indeed extremely similar. This is a common pattern -- if'ing stuff midly, if'ing stuff to heck, vs. splitting out in separate implementation with no ugly if'ing. OpenGL is in a similar boat here, except that it seems to be a disproof. It appears the Cygwin/X OpenGL functions use __cdecl while the Microsoft ones use __stdcall. Again the *.i3 files are almost the same, except for calling conventions, but it seems the "NT386 POSIX" variant uses a different calling convention than the "NT386 WIN32" variant. I am not 100% what is going on in OpenGL. Building "std" for NT386GNU gets at least as far as anim3d, however I haven't run much of the code at all -- only enough of cm3 to see it has a problem with paths... I'm still just using a "regular" NT386 in a sort of cross scenario. - Jay > Date: Mon, 11 Feb 2008 14:12:03 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > Olaf, yes you understand me.> >> > I strongly object to calling it SYSAPI however, or pretty much any > > attempt at further abstraction here.> >> > I would consider some sort of qualifier that says when to pay > > attention, when to ignore.> > For example using a platform name, <*external NT386:WINAPI*>.> > This is edging toward "preprocessing" but an incredibly small step.> > (Even though a big problem with preprocessing is rampant context > > sensitivity, sensitivity to what the target is, and reparsing for > > every target, is reasonable, and is how M3 already works.)> >> > It isn't the "system" calling convention really, it is just very > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > many of them happen to use __stdcall aka WINAPI a lot, but not all, > > and not for all functions. "system" MIGHT be how you call the > > kernel, but that is different. (calling the kernel is not directly > > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is).> > OK, so it's not system specific, but its system specific that there> are multiple calling conventions for Windows. However, I'm still not> convinced that this may affect only Windows systems and no others.> It may sound academic, but wouldn't it be possible that suddenly> Apple (or even some new OS player :) comes up with similar distinctions?> > I think we shouldn't implement a pragma convention that is usable> only for Windows, but one that is more generic. If we can just> extend your example to something like> > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*>> > this would be better.> > As for the semantic differences on different target platforms, I think> we could live with them given that all this stuff is system dependent> and unsafe anyway, but I'd like to hear the opinion of others on this> topic, too.> > Olaf> > > msvcrt.dll uses __cdecl for the most part.> > Anything that accepts varargs, which is very few functions, uses > > __cdecl, out of necessity (at least give a "normal" point of view, I > > did used to use a system where calleee popped varargs...).> > If you write drivers, a small number of functions are __fastcall.> > I would rather drop the synonyms and just have __cdecl, __fastcall, > > __stdcall, than to invent "SYSAPI".> > However I don't really want to do that, "WINAPI" and the other names > > are useful for a more literal translation of headers.> > There is a mix of calling conventions on x86 Windows and there is > > not really one "SYSAPI".> >> > The negative affects of changing the default calling convention is > > breaking all existing dynamic links where you only rebuild one side > > and where the calling convention wasn't explicit (all of them). Very > > very bad.> >> > > you'd like to declare the external procedures as WINAPI in general> >> > Not quite in general perhaps.> > But I guess any file for which someone has portable C and it is > > built for NT386 and anything else.> > Explicit calling conventions are always reasonable on NT386 and > > never reasonable anywhere else.> > The Visual C++ compiler has a command line switch as to what the > > default calling convention is, and widely used headers should work > > no matter what is the default.> > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 14:33:42 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:33:42 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Message-ID: > If you are really lazy, you can always use the NOWARN pragma: What if I am really really really lazy? :) > I wouldn't like to see any changes here. ok. - Jay > Date: Mon, 11 Feb 2008 14:17:56 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] imports anywhere?> > Quoting Jay :> > > Here is another SMALL gripe with the language.> > The need to put IMPORTS at the top (or is it just common style?), > > leads to something I have seen several times.> > You comment out some code, thereby deleting the only/last use of > > some import, that nets you warnings about unused imports. Granted, > > they are "only" warnings, but I try to have none. Also granted, you > > can either comment out or just go ahead and remove the imports, easy.> >> > It might be nice if the IMPORTS could be adjacent to the code using > > the IMPORTS, so that they can be comment out or removed together.> >> > This "problem" is not unique to Modula-3, by far.> > In fact, Modula-3 is probably more able to warn about this low cost > > waste due to its much better module system, compared to say, C and > > C++ #includes..> > I wouldn't like to see any changes here.> > It is good that all the imports are explicit, and it is good that> they are at the top (to define the dependencies). It's not much> effort to add or remove an import for debugging etc.> > If you are really lazy, you can always use the NOWARN pragma:> > IMPOPRT IO <*NOWARN*>> > to suppres the warnings for that declaration. That was not your> point though.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 15:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 14:38:14 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211142730.E6B3A10D4655@birch.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: It'd be nice if I could declare externals in modules. In this example, setitimer_ only exists for the wrapper implementation. I don't need it to be visible outside the one module that uses it. I guess I could push it into an unexposed interface, even dedicate "internal.i3" to it?Is that an ok idiom? It's another problem that I don't know what to call these things.. - Jay > Date: Mon, 11 Feb 2008 15:27:30 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 15:27:30> > Modified files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 m3makefile > Added files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.m3 > > Log message:> make setitimer(ITIMER_VIRTUAL) always succeed, even though Cygwin> would always fail it (not so accurate a Unix emulation eh?)> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 16:02:40 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 16:02:40 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Quoting Jay : > It'd be nice if I could declare externals in modules. > In this example, setitimer_ only exists for the wrapper implementation. > I don't need it to be visible outside the one module that uses it. > I guess I could push it into an unexposed interface, even dedicate > "internal.i3" to it?Is that an ok idiom? Yes, use an internal interface of the package. But you should use another name (something longer and more unique), since the CM3 builder still has problems with multiple defined units AFAIK. This is something that should really be fixed, but that's another topic. (We'd need hierarchical name spaces, but introduce them in a compatible way.) Olaf > It's another problem that I don't know what to call these things.. This usually is _my_ problem :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 11 17:23:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:23:47 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: Message-ID: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Do we know that this actually results in any real performance improvement. On Feb 11, 2008, at 5:34 AM, Jay wrote: > __declspec(dllimport) is a nice little cheap optimization on Windows. > When you are calling a function that you will be dynamically > linking to, it saves one instructions per call. > > On Windows, the way dynamic linking works is that for all your > imports, there is one array of pointers in your .dll/.exe. > It could actually be discontiguous. It is an array per .dll rather, > with a terminal NULL for each .dll you import from. All the dynamic > loader does is write pointers into this array at load time. It does > not have to, like, go all through your code patching stuff up. > > If you just call Foo, but end up importing Foo, the linker > generates a one instruction function: > Foo: > jmp dword ptr[__imp__Foo] > > __imp__Foo is in that array that gets patched up. > > However if you declare Foo to be __declspec(dllimport), the > compiler will instead of: > call Foo > generate: > call dword ptr[__imp__Foo] > > in fact, if you have multiple nearby calls to Foo, the compiler > knows these pointers are "relatively const" and will fetch the > pointer and hold it in a register and make the calls through the > register. > > There is a problem with __declspec(dllimport). > Essentially, you know, for every imported function Foo, there is > somewhere out there someone implementing it. > They are not importing it. They are exporting it. > While getting this declaration wrong is actually "ok", it ends up > costing the implementer an extra instruction on their calls, and > generates a linker warning ("importing local function"). > > So what ends up happening usually is either a) the implementer > doesn't #include his own header files, generally a bad bad bad idea > or b) for every .dll bar.dll, a macro is made up BARAPI and then > the code usually goes like: > > #ifndef BARAPI > #define BARAPI __declspec(dllimport) > #endif > > BARAPI void __stdcall Foo(void); > > and the implementer will define BARAPI to either be nothing/empty, > or __declspec(dllexport). > (__declspec(dllexport) is another topic, I'll try not to go into > here.) > > This is a little gross, this proliferation of "cover" macros for > __declspec(dllimport). > But it IS a nice little optimization. > Actually I suspect many people think these annotations are required. > But they almost never ever are. But they are nice to have. > > So, what do people think? > Worth some syntax? In <*extern*> pragmas? > Gcc already understand this stuff I believe. > I think I noticed it when looking at the __stdcall stuff. > > Another wrinkle here is that Modula-3 has this nice build_standalone > () feature, which switches whether or not you dynamically link. It > would tend to invalidate statements here, at least about Modula-3 > code. > > On the matter of when __declspec(dllimport) is needed. > - I'm not sure about C++ classes. You should just never import > then really, but use COM instead, but people do. > (COM is just using pure virtual function calls -- ie: calls > through structs containing all function pointers, and get a pointer > to said struct via a special C creation function). > > - It is needed for data, at least with Microsoft tools. The GNU > tools seem to have some workaround here. > Notice I pointed out the linker generates a function for you if > you don't make the annotation. You can't intervene on data accesses > with a function call, unless, say, you've inserted a function call > for every single data access, or if you can still go back and > change the code, like at link time. Data imports are rare and I > suggest just never use them. But they are much faster when they > suffice, true. > > __declspec(dllexport) can generally just be replaced with a .def file. > - again, I don't know about C++ classes > - for C++ functions, the .def file will contain some ugly > processor-specific mangled names, a little bit difficult/annoying > to come up with and put in the .def file, but not impossible by far > (link /dump /symbols | findstr /v UNDEF for example) > - again, just don't export C++ classes, or mangled/overloaded/ > etc. names, only export C functions and you are set with a .def > file; this also aids compatibility with multiple compilers and > languages (!) > - (C++ is largely well and good and I can tell you what is good > about it, but one thing it is NOT good for is defining dynamically > linked interfaces; I think Modula-3 can get into the same trap -- > e.g. traffic only in a few base types (integer, text) and opaque > types, don't let dynamically linked callers know about your record > format/offsets, else you'll have to recompile "too often") > > __declspec(dllexport) provides no optimization analogous to > __declspec(dllimport). > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Feb 11 17:26:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:26:50 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: Why not simply default EXTERNAL on Win32 to WINAPI instead? That way, all EXTERNALs will look the same but you won't clutter up non- Win32 with ugly WINAPI. On Feb 11, 2008, at 5:13 AM, Jay wrote: > I know this won't be popular but... > > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > > The differences are > > the UNUSED type SQLHWND is ADDRESS or HWND > This should just be removed. > > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > > For this and other reasons, I suggest that all CM3 frontends accept > but silently > ignore the Win32/x86 calling conventions in <*external*> pragmas, > similar to what the non-x86 Windows compilers do. > > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing. > It is a small safe change that will allow a little more Modula-3 > source portability. > > A similar suggestion would be to change the default calling > convention in Modula-3, > it would very possibly reduce code size, but is very very very much > a breaking > change so probably can never happen. > Better probably would be to a) add a switch for this b) extend > the .m3exports > or whatnot files to indicate what switch was used. > > A "blanket pragma" might also be good, so that the various *.i3 > files can > say just to assume __stdcall for the rest of the file instead of > annotating each functions. > > - Jay > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:28:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:28:56 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: <38355684-DFFB-43B0-81D9-D6745EA195BB@cs.purdue.edu> On Feb 11, 2008, at 8:31 AM, Jay wrote: > I don't think anyone else will commit the error of having multiple > calling conventions. > It's a bad place to be. > Granted, kernels often do have an unusual calling convention, but > that gets wrapped up in something "normal". > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > In practice this will only ever be: > > > <*EXTERNAL NT386:WINAPI *> I can live with this. > > > and I am satisfied. :) > > oh, btw, the other obvious: > > <*NT386:EXTERNAL WINAPI *> > > or even in general both -- pragms can all be prefixed with a platform. > In practise, "external" is platform-independent, calling convention > is not. > > There might be exceptions, where particular platforms require a > Modula-3 wrapper. As Cygwin had briefly for semaphore > initialization. I guess this really does in general resemble > preprocessing, only by target, only of pragmas, and the point > really is to limit per-platform branching when the platforms are > indeed extremely similar. > > This is a common pattern -- if'ing stuff midly, if'ing stuff to > heck, vs. splitting out in separate implementation with no ugly > if'ing. > > OpenGL is in a similar boat here, except that it seems to be a > disproof. > It appears the Cygwin/X OpenGL functions use __cdecl while the > Microsoft ones use __stdcall. > Again the *.i3 files are almost the same, except for calling > conventions, but it seems the "NT386 POSIX" variant uses a > different calling convention than the "NT386 WIN32" variant. > > I am not 100% what is going on in OpenGL. Building "std" for > NT386GNU gets at least as far as anim3d, however I haven't run much > of the code at all -- only enough of cm3 to see it has a problem > with paths... I'm still just using a "regular" NT386 in a sort of > cross scenario. > > - Jay > > > > Date: Mon, 11 Feb 2008 14:12:03 +0100 > > From: wagner at elegosoft.com > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] <*external winapi*> silently ignored on > all platforms? > > > > Quoting Jay : > > > Olaf, yes you understand me. > > > > > > I strongly object to calling it SYSAPI however, or pretty much any > > > attempt at further abstraction here. > > > > > > I would consider some sort of qualifier that says when to pay > > > attention, when to ignore. > > > For example using a platform name, <*external NT386:WINAPI*>. > > > This is edging toward "preprocessing" but an incredibly small > step. > > > (Even though a big problem with preprocessing is rampant context > > > sensitivity, sensitivity to what the target is, and reparsing for > > > every target, is reasonable, and is how M3 already works.) > > > > > > It isn't the "system" calling convention really, it is just very > > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > > many of them happen to use __stdcall aka WINAPI a lot, but not > all, > > > and not for all functions. "system" MIGHT be how you call the > > > kernel, but that is different. (calling the kernel is not directly > > > exposed in Win32, "kernel32.dll" is not the kernel, > ntoskrnl.exe is). > > > > OK, so it's not system specific, but its system specific that there > > are multiple calling conventions for Windows. However, I'm still not > > convinced that this may affect only Windows systems and no others. > > It may sound academic, but wouldn't it be possible that suddenly > > Apple (or even some new OS player :) comes up with similar > distinctions? > > > > I think we shouldn't implement a pragma convention that is usable > > only for Windows, but one that is more generic. If we can just > > extend your example to something like > > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > > > this would be better. > > > > As for the semantic differences on different target platforms, I > think > > we could live with them given that all this stuff is system > dependent > > and unsafe anyway, but I'd like to hear the opinion of others on > this > > topic, too. > > > > Olaf > > > > > msvcrt.dll uses __cdecl for the most part. > > > Anything that accepts varargs, which is very few functions, uses > > > __cdecl, out of necessity (at least give a "normal" point of > view, I > > > did used to use a system where calleee popped varargs...). > > > If you write drivers, a small number of functions are __fastcall. > > > I would rather drop the synonyms and just have __cdecl, > __fastcall, > > > __stdcall, than to invent "SYSAPI". > > > However I don't really want to do that, "WINAPI" and the other > names > > > are useful for a more literal translation of headers. > > > There is a mix of calling conventions on x86 Windows and there is > > > not really one "SYSAPI". > > > > > > The negative affects of changing the default calling convention is > > > breaking all existing dynamic links where you only rebuild one > side > > > and where the calling convention wasn't explicit (all of them). > Very > > > very bad. > > > > > > > you'd like to declare the external procedures as WINAPI in > general > > > > > > Not quite in general perhaps. > > > But I guess any file for which someone has portable C and it is > > > built for NT386 and anything else. > > > Explicit calling conventions are always reasonable on NT386 and > > > never reasonable anywhere else. > > > The Visual C++ compiler has a command line switch as to what the > > > default calling convention is, and widely used headers should work > > > no matter what is the default. > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:33:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:33:07 -0500 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <8B8213B4-3DBF-47CE-BC3E-1EE96B5F43F6@cs.purdue.edu> On Feb 11, 2008, at 4:15 AM, Jay wrote: > Aren't we better off with more VAR parameters and fewer UNTRACED REFs? > That way more interfaces/modules can be "safe", as this one changed? Indeed! I agree. > > > (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) > (Maybe a "DJGPP" target will satisfy? :) ) I barely care about Windows :-), whatever version you choose. > > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:13:41 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:13:41 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > > > Log message: > > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > > instead of GetSystemTime + SystemTimeToFileTime > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:34:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:34:54 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> You can, except you need to explicitly give the block scope: VAR ... BEGIN ... END; I find this much better than C++ where the scope of the new variable is imprecisely defined. On Feb 11, 2008, at 4:29 AM, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and > the compiler might do stack packing anyway, you can move all your > locals up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is > often so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 ! > = t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:38:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:38:48 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> On Feb 11, 2008, at 6:23 AM, Jay wrote: > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > INTEGER; > > really? it is signed? > and we are sure this is going to be 64 bits on 64 bit targets? > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > That has a 32 bit and 64 bit version, at least. These are OS-dependent! They should not be in BasicCtypes. > > > Does INTEGER effectively equal int or ptrdiff_t? > > - Jay > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:40:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:40:11 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: I hate imports that are scattered throughout since it hides dependencies deep in the guts of the code. Much better to have them explicit at the top! On Feb 11, 2008, at 7:48 AM, Jay wrote: > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and C > ++ #includes.. From hosking at cs.purdue.edu Mon Feb 11 17:41:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:41:24 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: Please -- no hierarchical namespaces. Ultimately, they need a definitive hierarchy anyway. On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > Quoting Jay : > >> It'd be nice if I could declare externals in modules. >> In this example, setitimer_ only exists for the wrapper >> implementation. >> I don't need it to be visible outside the one module that uses it. >> I guess I could push it into an unexposed interface, even >> dedicate "internal.i3" to it?Is that an ok idiom? > > Yes, use an internal interface of the package. But you should use > another name (something longer and more unique), since the CM3 > builder still has problems with multiple defined units AFAIK. > > This is something that should really be fixed, but that's another > topic. (We'd need hierarchical name spaces, but introduce them in > a compatible way.) > > Olaf > >> It's another problem that I don't know what to call these things.. > > This usually is _my_ problem :-) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Mon Feb 11 17:42:00 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:42:00 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Message-ID: <20080211164200.GB20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: > Do we know that this actually results in any real performance > improvement. Not clear -- hardware is getting pretty clever at doing at run-time the things that compilers used to sweat blood doing at compile time. I suspect that with fetch-and-branch-predictiong processors, the difference may unmeasurable. -- hendrik From hendrik at topoi.pooq.com Mon Feb 11 17:50:54 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:50:54 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211165054.GC20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:40:11AM -0500, Tony Hosking wrote: > I hate imports that are scattered throughout since it hides > dependencies deep in the guts of the code. Much better to have them > explicit at the top! > > On Feb 11, 2008, at 7:48 AM, Jay wrote: > > >Here is another SMALL gripe with the language. > >The need to put IMPORTS at the top (or is it just common style?), > >leads to something I have seen several times. > >You comment out some code, thereby deleting the only/last use of > >some import, that nets you warnings about unused imports. Granted, > >they are "only" warnings, but I try to have none. Also granted, you > >can either comment out or just go ahead and remove the imports, easy. > > > >It might be nice if the IMPORTS could be adjacent to the code using > >the IMPORTS, so that they can be comment out or removed together. > > > >This "problem" is not unique to Modula-3, by far. > >In fact, Modula-3 is probably more able to warn about this low cost > >waste due to its much better module system, compared to say, C and C > >++ #includes.. > I don't know if this is still the case, but long long ago, when I was reading the OS/2 port of Modula 3, there seemed to be an early phase that determined which source files had to be compiled. It could determine this from just the beginnings of the source files, and did not have to do full-scale Modula 3 parsing. I thought it a clever engineering trick. -- hendrik From rcoleburn at scires.com Mon Feb 11 17:58:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 11 Feb 2008 11:58:15 -0500 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <47B03853.1E75.00D7.1@scires.com> Jay: Not sure exactly what you are doing and how my answer will impact what you are doing, but here is my 2 cents. If there is stuff out there to deal with these old computers, we shouldn't remove it just because they are old. I still have Modula-3 code that is running on old computers. Indeed, the government tends to have some interesting requirements to keep alive certain systems that use old technology. I have delivered many systems over the course of my career whose actual lifetime was much longer than what anyone projected in the beginning. If we remove support for the old stuff, then we shoot ourselves in the foot for any type of support on these old systems. Indeed, I've recently been approached about making some changes to a system that I first developed back in the late 1990's. It is still around and working. One of the system components has been upgraded and they want me to make software changes to let the Modula-3 code work with the new component. This software controls and monitors satellite radio communications systems. Regards, Randy >>> Jay 2/11/2008 4:35 AM >>> ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs? That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/11 10:13:41 > > Modified files: > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message: > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > instead of GetSystemTime + SystemTimeToFileTime > Need to know the score, the latest news, or you need your Hotmail*-get your "fix". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) Climb to the top of the charts! Play the word scramble challenge with star power. Play now! ( http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 17:59:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:59:40 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <20080211164200.GB20791@topoi.pooq.com> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> Message-ID: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> My thoughts exactly. Let's not expend effort for no gain! On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote: > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: >> Do we know that this actually results in any real performance >> improvement. > > Not clear -- hardware is getting pretty clever at doing at run-time > the > things that compilers used to sweat blood doing at compile time. I > suspect that with fetch-and-branch-predictiong processors, the > difference may > unmeasurable. > > -- hendrik From wagner at elegosoft.com Mon Feb 11 18:19:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 18:19:59 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Quoting Tony Hosking : > Please -- no hierarchical namespaces. Ultimately, they need a > definitive hierarchy anyway. I wasn't going to write the code, so no need to worry. However, if this is not the solution we aim at, then we need to do something else about the increasing probability of the builder failing because some module in a completely different package which I don't even use directly happens to have the same name as my internal module and thus cannot be compiled. Or even worse: if I use two packages that happen to contain one module of the same name and have never been used together before. Olaf PS: This reminds me of Leslie Lamports definition of distributed computing: when a computer you didn't even know existed can render your own computer unusable :) > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> Quoting Jay : >> >>> It'd be nice if I could declare externals in modules. >>> In this example, setitimer_ only exists for the wrapper implementation. >>> I don't need it to be visible outside the one module that uses it. >>> I guess I could push it into an unexposed interface, even dedicate >>> "internal.i3" to it?Is that an ok idiom? >> >> Yes, use an internal interface of the package. But you should use >> another name (something longer and more unique), since the CM3 >> builder still has problems with multiple defined units AFAIK. >> >> This is something that should really be fixed, but that's another >> topic. (We'd need hierarchical name spaces, but introduce them in >> a compatible way.) >> >> Olaf >> >>> It's another problem that I don't know what to call these things.. >> >> This usually is _my_ problem :-) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Feb 11 18:52:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 12:52:33 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: This would be a bigger issue if we had dynamic loading like Java. To some degree, m3makefile imports give us some protection against name clashes. But, I do see your point that a name clash may prevent reuse of separately developed packages. On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Please -- no hierarchical namespaces. Ultimately, they need a >> definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf > > PS: This reminds me of Leslie Lamports definition of distributed > computing: when a computer you didn't even know existed > can render your own computer unusable :) > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >> >>> Quoting Jay : >>> >>>> It'd be nice if I could declare externals in modules. >>>> In this example, setitimer_ only exists for the wrapper >>>> implementation. >>>> I don't need it to be visible outside the one module that uses it. >>>> I guess I could push it into an unexposed interface, even >>>> dedicate "internal.i3" to it?Is that an ok idiom? >>> >>> Yes, use an internal interface of the package. But you should use >>> another name (something longer and more unique), since the CM3 >>> builder still has problems with multiple defined units AFAIK. >>> >>> This is something that should really be fixed, but that's another >>> topic. (We'd need hierarchical name spaces, but introduce them in >>> a compatible way.) >>> >>> Olaf >>> >>>> It's another problem that I don't know what to call these things.. >>> >>> This usually is _my_ problem :-) >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hendrik at topoi.pooq.com Mon Feb 11 21:06:13 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 15:06:13 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <20080211200613.GA20997@topoi.pooq.com> On Mon, Feb 11, 2008 at 06:19:59PM +0100, Olaf Wagner wrote: > Quoting Tony Hosking : > > >Please -- no hierarchical namespaces. Ultimately, they need a > >definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf Packages are a lot like modules on a larger scale. Maybe we should be able to syntactically nest modules? And enable modules to export some of their submodules? Or, if the source file gets unwieldy (it will!), use the nesting structure of directories as part of the syntax of the language? Or, for another approach: The various Eiffel implementations have separate module-interconnection language in which they get to collect modules into groups, and indicate some are internal to the group, and also things like <>, or <>. They set this up with programming-language syntax, syntactic nesting, indentation, and so forth. It seems to work, and you don't have to embed everything into an unweildy world-wide, global namespace. But the different implementations seem to have grown their own interconnection languages :-( -- hendrik From jayk123 at hotmail.com Mon Feb 11 22:42:30 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:42:30 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: Lack of hierarchical namespaces in Modula-3 has long bugged me, but I actually pretty much got over it. So agreed. :) Yes it sounds like the builder, not the language, has a bug. - Jay > Date: Mon, 11 Feb 2008 18:19:59 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] external in module?> > Quoting Tony Hosking :> > > Please -- no hierarchical namespaces. Ultimately, they need a> > definitive hierarchy anyway.> > I wasn't going to write the code, so no need to worry.> However, if this is not the solution we aim at, then we need to> do something else about the increasing probability of the builder> failing because some module in a completely different package> which I don't even use directly happens to have the same name> as my internal module and thus cannot be compiled. Or even worse:> if I use two packages that happen to contain one module of the> same name and have never been used together before.> > Olaf> > PS: This reminds me of Leslie Lamports definition of distributed> computing: when a computer you didn't even know existed> can render your own computer unusable :)> > > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote:> >> >> Quoting Jay :> >>> >>> It'd be nice if I could declare externals in modules.> >>> In this example, setitimer_ only exists for the wrapper implementation.> >>> I don't need it to be visible outside the one module that uses it.> >>> I guess I could push it into an unexposed interface, even dedicate > >>> "internal.i3" to it?Is that an ok idiom?> >>> >> Yes, use an internal interface of the package. But you should use> >> another name (something longer and more unique), since the CM3> >> builder still has problems with multiple defined units AFAIK.> >>> >> This is something that should really be fixed, but that's another> >> topic. (We'd need hierarchical name spaces, but introduce them in> >> a compatible way.)> >>> >> Olaf> >>> >>> It's another problem that I don't know what to call these things..> >>> >> This usually is _my_ problem :-)> >> -- > >> Olaf Wagner -- elego Software Solutions GmbH> >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:44:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:44:18 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:51:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:51:10 +0000 Subject: [M3devel] size_t? In-Reply-To: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: > These are OS-dependent! They should not be in BasicCtypes. 1) There is no Utypes on Windows. These are very basic types that belong at a very low level. In C++ for example, size_t is provided "automatically" by the compiler, no header is needed. 2) Are they really OS dependent? What OS makes my definitions wrong? On what 32 bit architecture is size_t not an unsigned 32 bit integer and ptrdiff_t not a signed 32 bit integer? Ditto for 64 bit. These should always be the same size as a pointer and with the proper signedness. Even if some of the *.i3 files make size_t = int, is that really correct? And, I assume int vs. long issue is not an issue here. Though they may be different types in C and C++, they need not be in Modula-3 (when they are the same size, of course) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 11:38:48 -0500> To: jayk123 at hotmail.com> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > INTEGER;> >> > really? it is signed?> > and we are sure this is going to be 64 bits on 64 bit targets?> >> > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > That has a 32 bit and 64 bit version, at least.> > These are OS-dependent! They should not be in BasicCtypes.> > >> >> > Does INTEGER effectively equal int or ptrdiff_t?> >> > - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:52:06 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:52:06 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: I guess I should switch the default calling convention and see what the code size difference is. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hendrik at topoi.pooq.comDate: Mon, 11 Feb 2008 21:44:18 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] __declspec(dllimport)? Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:56:55 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:56:55 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: If you want a precise scope in C++, just but in an opening brace. Just like how in Modula-3 (now I know) you can have "BEGIN" almost anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. It isn't often used though, granted. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] introducing VAR in more places?> Date: Mon, 11 Feb 2008 11:34:54 -0500> To: jayk123 at hotmail.com> > You can, except you need to explicitly give the block scope:> > VAR ...> BEGIN> ...> END;> > I find this much better than C++ where the scope of the new variable > is imprecisely defined.> > On Feb 11, 2008, at 4:29 AM, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and > > the compiler might do stack packing anyway, you can move all your > > locals up top like typical C, but still, how about for the module > > initializer?> > Still it seems good to me to do manual stack packing since it is > > often so easy..> > WITH helps, but only for "relative constants".> >> > It would be nice if the code below could have still loops until t0 ! > > = t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame..> >> > - Jay> >> >> >> > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > >> > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3> > >> > > Log message:> > > no need for globals here..> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 22:33:20 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 22:33:20 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <1202765600.8543.32.camel@faramir.m3w.org> But... We DO HAVE dynamic loading, and it's not altogether unlike Java :). Did these patches of mine made to CM3 HEAD? dd On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: > This would be a bigger issue if we had dynamic loading like Java. To > some degree, m3makefile imports give us some protection against name > clashes. But, I do see your point that a name clash may prevent > reuse of separately developed packages. > > On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > >> Please -- no hierarchical namespaces. Ultimately, they need a > >> definitive hierarchy anyway. > > > > I wasn't going to write the code, so no need to worry. > > However, if this is not the solution we aim at, then we need to > > do something else about the increasing probability of the builder > > failing because some module in a completely different package > > which I don't even use directly happens to have the same name > > as my internal module and thus cannot be compiled. Or even worse: > > if I use two packages that happen to contain one module of the > > same name and have never been used together before. > > > > Olaf > > > > PS: This reminds me of Leslie Lamports definition of distributed > > computing: when a computer you didn't even know existed > > can render your own computer unusable :) > > > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> > >>> Quoting Jay : > >>> > >>>> It'd be nice if I could declare externals in modules. > >>>> In this example, setitimer_ only exists for the wrapper > >>>> implementation. > >>>> I don't need it to be visible outside the one module that uses it. > >>>> I guess I could push it into an unexposed interface, even > >>>> dedicate "internal.i3" to it?Is that an ok idiom? > >>> > >>> Yes, use an internal interface of the package. But you should use > >>> another name (something longer and more unique), since the CM3 > >>> builder still has problems with multiple defined units AFAIK. > >>> > >>> This is something that should really be fixed, but that's another > >>> topic. (We'd need hierarchical name spaces, but introduce them in > >>> a compatible way.) > >>> > >>> Olaf > >>> > >>>> It's another problem that I don't know what to call these things.. > >>> > >>> This usually is _my_ problem :-) > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > >>> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 > >>> 23 45 86 95 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 23:03:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:03:22 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: That's also a good idea too. Though I think maybe safer to say: <*NT386:callingconvention push*><*NT386:callingconvention winapi*> ..bunch of decls .. <*NT386:callingconvention pop*> > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI. Tony, is /everything/ Win32 ugly? :) The status of SQLHWND is less clear to me now, seems I have trouble with the basic find-in-files.. Even so -- it used like once, its type is almost the same, the Windef definition is now available, the headers are almost the same. I did notice the Win32 headers actually #ifdef: #if defined(WIN32) || defined(OS2)typedef HWND SQLHWND;#elif defined (UNIX)typedef Widget SQLHWND;#else/* placehold for future O/S GUI window handle definition */typedef SQLPOINTER SQLHWND;#endif Might be nice to have a limited form of #if in Modula-3. I understand -- don't want to have to parse headers over and over. Maybe only if on TARGET and nothing else? Slippery slope. So far ODBC is the main place I've seen this and I'm just about over it. The status of OpenGL here isn't clear, seems maybe the opposite -- __stdcall on NT386, __cdecl on NT386GNU. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> Date: Mon, 11 Feb 2008 11:26:50 -0500> To: jayk123 at hotmail.com> > Why not simply default EXTERNAL on Win32 to WINAPI instead? That > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI.> > On Feb 11, 2008, at 5:13 AM, Jay wrote:> > > I know this won't be popular but...> >> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> >> > The differences are> >> > the UNUSED type SQLHWND is ADDRESS or HWND> > This should just be removed.> >> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> >> > For this and other reasons, I suggest that all CM3 frontends accept > > but silently> > ignore the Win32/x86 calling conventions in <*external*> pragmas,> > similar to what the non-x86 Windows compilers do.> >> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> >> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.> > It is a small safe change that will allow a little more Modula-3 > > source portability.> >> > A similar suggestion would be to change the default calling > > convention in Modula-3,> > it would very possibly reduce code size, but is very very very much > > a breaking> > change so probably can never happen.> > Better probably would be to a) add a switch for this b) extend > > the .m3exports> > or whatnot files to indicate what switch was used.> >> > A "blanket pragma" might also be good, so that the various *.i3 > > files can> > say just to assume __stdcall for the rest of the file instead of > > annotating each functions.> >> > - Jay> >> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:04:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:04:10 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Sorry. They belong in Cstddef.i3. size_t is already there. Let's try to stick to the C ".h" structure. size_t = INTEGER. On Feb 11, 2008, at 4:51 PM, Jay wrote: > > These are OS-dependent! They should not be in BasicCtypes. > > 1) There is no Utypes on Windows. > These are very basic types that belong at a very low level. > In C++ for example, size_t is provided "automatically" by the > compiler, no header is needed. > > 2) Are they really OS dependent? What OS makes my definitions wrong? > On what 32 bit architecture is size_t not an unsigned 32 bit > integer and ptrdiff_t not a signed 32 bit integer? > Ditto for 64 bit. > These should always be the same size as a pointer and with the > proper signedness. > Even if some of the *.i3 files make size_t = int, is that really > correct? > And, I assume int vs. long issue is not an issue here. > Though they may be different types in C and C++, they need not be > in Modula-3 (when they are the same size, of course) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > To: jayk123 at hotmail.com > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > > INTEGER; > > > > > > really? it is signed? > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > That has a 32 bit and 64 bit version, at least. > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 11 23:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:34:27 +0000 Subject: [M3devel] size_t? In-Reply-To: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: I did later notice size_t was there. I think what I earlier noticed was ptrdiff_t nowhere. > size_t = INTEGER. But unsigned presumably? What I had was correct, right? In C++ no header is needed for size_t, it is just so basic and widespread. Not sure about ptrdiff_t. Either way, they both do live in that middle ground between compiler and library -- a very low level -- as size_t is defined as the type of sizeof() expressions and ptrdiff_t is defined as the type you get when you subtract pointers. And you don't need nay header to use sizeof() or subtract pointers. If it were really up to me, I'd have the Modula-3 language predefine all of int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. There is a corralary dilemna here that I haven't figured out, and have seen code address that I haven't adjusted to yet. That is, the code uses uint32 "everywhere", instead of something "more abstract/vague". When it comes down to it, I suspect this is the right thing. The abstraction only seems to buy problems. UNLESS you have a processor with a larger natural integer that performs poorly on smaller integers, or a processor that perfs badly with 32 bit integers. Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. In many and growing systems, "int", besides its signedness, is too small for many occurences. That is the problem I think in C. If Modula-3 has essentially defined INTEGER to be the size of a pointer, then ok. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 17:04:10 -0500> To: jayk123 at hotmail.com> > Sorry.> > They belong in Cstddef.i3. size_t is already there. Let's try to > stick to the C ".h" structure.> > size_t = INTEGER.> > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > > > These are OS-dependent! They should not be in BasicCtypes.> >> > 1) There is no Utypes on Windows.> > These are very basic types that belong at a very low level.> > In C++ for example, size_t is provided "automatically" by the > > compiler, no header is needed.> >> > 2) Are they really OS dependent? What OS makes my definitions wrong?> > On what 32 bit architecture is size_t not an unsigned 32 bit > > integer and ptrdiff_t not a signed 32 bit integer?> > Ditto for 64 bit.> > These should always be the same size as a pointer and with the > > proper signedness.> > Even if some of the *.i3 files make size_t = int, is that really > > correct?> > And, I assume int vs. long issue is not an issue here.> > Though they may be different types in C and C++, they need not be > > in Modula-3 (when they are the same size, of course)> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > To: jayk123 at hotmail.com> > >> > >> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > >> > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t => > > > INTEGER;> > > >> > > > really? it is signed?> > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > >> > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > That has a 32 bit and 64 bit version, at least.> > >> > > These are OS-dependent! They should not be in BasicCtypes.> > >> > > >> > > >> > > > Does INTEGER effectively equal int or ptrdiff_t?> > > >> > > > - Jay> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:40:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:40:44 -0500 Subject: [M3devel] external in module? In-Reply-To: <1202765600.8543.32.camel@faramir.m3w.org> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> <1202765600.8543.32.camel@faramir.m3w.org> Message-ID: Not sure... On Feb 11, 2008, at 4:33 PM, Dragi?a Duri? wrote: > But... We DO HAVE dynamic loading, and it's not altogether unlike > Java :). > > Did these patches of mine made to CM3 HEAD? > > dd > > On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: >> This would be a bigger issue if we had dynamic loading like Java. To >> some degree, m3makefile imports give us some protection against name >> clashes. But, I do see your point that a name clash may prevent >> reuse of separately developed packages. >> >> On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> Please -- no hierarchical namespaces. Ultimately, they need a >>>> definitive hierarchy anyway. >>> >>> I wasn't going to write the code, so no need to worry. >>> However, if this is not the solution we aim at, then we need to >>> do something else about the increasing probability of the builder >>> failing because some module in a completely different package >>> which I don't even use directly happens to have the same name >>> as my internal module and thus cannot be compiled. Or even worse: >>> if I use two packages that happen to contain one module of the >>> same name and have never been used together before. >>> >>> Olaf >>> >>> PS: This reminds me of Leslie Lamports definition of distributed >>> computing: when a computer you didn't even know existed >>> can render your own computer unusable :) >>> >>>> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >>>> >>>>> Quoting Jay : >>>>> >>>>>> It'd be nice if I could declare externals in modules. >>>>>> In this example, setitimer_ only exists for the wrapper >>>>>> implementation. >>>>>> I don't need it to be visible outside the one module that uses >>>>>> it. >>>>>> I guess I could push it into an unexposed interface, even >>>>>> dedicate "internal.i3" to it?Is that an ok idiom? >>>>> >>>>> Yes, use an internal interface of the package. But you should use >>>>> another name (something longer and more unique), since the CM3 >>>>> builder still has problems with multiple defined units AFAIK. >>>>> >>>>> This is something that should really be fixed, but that's another >>>>> topic. (We'd need hierarchical name spaces, but introduce them in >>>>> a compatible way.) >>>>> >>>>> Olaf >>>>> >>>>>> It's another problem that I don't know what to call these >>>>>> things.. >>>>> >>>>> This usually is _my_ problem :-) >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>>>> 23 45 86 95 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>> Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Feb 12 00:37:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 18:37:56 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. Subtracting two pointers yields ptrdiff_t, so in M3 it would presumably be INTEGER. size_t is what sizeof returns, so I imagine size_t=CARDINAL is probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should better be Word.T to match C's unsigned interpretation. Of course, Word.T is simply INTEGER anyway in the current CM3 implementation. Note that neither of these need to be defined in the 32bit/64bit subdirectories since they are straightforwardly the same as the underlying word size. On Feb 11, 2008, at 5:34 PM, Jay wrote: > I did later notice size_t was there. > I think what I earlier noticed was ptrdiff_t nowhere. > > > size_t = INTEGER. > > But unsigned presumably? > > What I had was correct, right? > In C++ no header is needed for size_t, it is just so basic and > widespread. > Not sure about ptrdiff_t. > > Either way, they both do live in that middle ground between > compiler and library -- a very low level -- > as size_t is defined as the type of sizeof() expressions and > ptrdiff_t is defined as the type you get when you subtract > pointers. And you don't need nay header to use sizeof() or subtract > pointers. > > If it were really up to me, I'd have the Modula-3 language > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > There is a corralary dilemna here that I haven't figured out, and > have seen code address that I haven't adjusted to yet. That is, the > code uses uint32 "everywhere", instead of something "more abstract/ > vague". When it comes down to it, I suspect this is the right > thing. The abstraction only seems to buy problems. UNLESS you have > a processor with a larger natural integer that performs poorly on > smaller integers, or a processor that perfs badly with 32 bit > integers. > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > In many and growing systems, "int", besides its signedness, is too > small for many occurences. > That is the problem I think in C. If Modula-3 has essentially > defined INTEGER to be the size of a pointer, then ok. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > To: jayk123 at hotmail.com > > > > Sorry. > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > stick to the C ".h" structure. > > > > size_t = INTEGER. > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > 1) There is no Utypes on Windows. > > > These are very basic types that belong at a very low level. > > > In C++ for example, size_t is provided "automatically" by the > > > compiler, no header is needed. > > > > > > 2) Are they really OS dependent? What OS makes my definitions > wrong? > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > integer and ptrdiff_t not a signed 32 bit integer? > > > Ditto for 64 bit. > > > These should always be the same size as a pointer and with the > > > proper signedness. > > > Even if some of the *.i3 files make size_t = int, is that really > > > correct? > > > And, I assume int vs. long issue is not an issue here. > > > Though they may be different types in C and C++, they need not be > > > in Modula-3 (when they are the same size, of course) > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > size_t = > > > > > INTEGER; > > > > > > > > > > really? it is signed? > > > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > - Jay > > > > > > Need to know the score, the latest news, or you need your > Hotmail?- > > > get your "fix". Check it out. > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Tue Feb 12 02:05:39 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:05:39 +0000 Subject: [M3devel] size_t? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: I think ANSI C is a bit of a mess here. For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... Anyway.. But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. For example, strlen returns size_t, so #include must define it (directly or indirectly). Malloc takes size_t, so #include must define it (directly or indirectly). fread/fwrite/stdio.h ditto. I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). Pushing some things into fewer larger integers is a step in this direction. It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. So maybe just size_t is missing? I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? Good enough? Really, I'm sure you have all figured out, I want Modula-3 to look more like C. :) The more I use C lately (as opposed to C++) and the more I use Modula-3 lately..the more I find C perfectly ok, the unsafety easy enough to not be bitten by, the more the heap allocations and copying that "safety" cost seem not worth it.. It's an interesting system largely just because it is yet another system, in need (arguably) of more targets, and where "NT386" exists but gets little support. Someone who "likes" Modula-3 more would serve it better than me, perhaps. But I'm here. :) I also like that a decent module system was worked out such as to build fast, at least when using the integrated backend. So maybe I just write all my Modula-3 as "unsafe" and be happy. :) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 18:37:56 -0500> To: jayk123 at hotmail.com> > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h.> > Subtracting two pointers yields ptrdiff_t, so in M3 it would > presumably be INTEGER.> size_t is what sizeof returns, so I imagine size_t=CARDINAL is > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > better be Word.T to match C's unsigned interpretation. Of course, > Word.T is simply INTEGER anyway in the current CM3 implementation. > Note that neither of these need to be defined in the 32bit/64bit > subdirectories since they are straightforwardly the same as the > underlying word size.> > On Feb 11, 2008, at 5:34 PM, Jay wrote:> > > I did later notice size_t was there.> > I think what I earlier noticed was ptrdiff_t nowhere.> >> > > size_t = INTEGER.> >> > But unsigned presumably?> >> > What I had was correct, right?> > In C++ no header is needed for size_t, it is just so basic and > > widespread.> > Not sure about ptrdiff_t.> >> > Either way, they both do live in that middle ground between > > compiler and library -- a very low level --> > as size_t is defined as the type of sizeof() expressions and > > ptrdiff_t is defined as the type you get when you subtract > > pointers. And you don't need nay header to use sizeof() or subtract > > pointers.> >> > If it were really up to me, I'd have the Modula-3 language > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER.> > There is a corralary dilemna here that I haven't figured out, and > > have seen code address that I haven't adjusted to yet. That is, the > > code uses uint32 "everywhere", instead of something "more abstract/ > > vague". When it comes down to it, I suspect this is the right > > thing. The abstraction only seems to buy problems. UNLESS you have > > a processor with a larger natural integer that performs poorly on > > smaller integers, or a processor that perfs badly with 32 bit > > integers.> >> > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t.> > In many and growing systems, "int", besides its signedness, is too > > small for many occurences.> > That is the problem I think in C. If Modula-3 has essentially > > defined INTEGER to be the size of a pointer, then ok.> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 17:04:10 -0500> > > To: jayk123 at hotmail.com> > >> > > Sorry.> > >> > > They belong in Cstddef.i3. size_t is already there. Let's try to> > > stick to the C ".h" structure.> > >> > > size_t = INTEGER.> > >> > > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > >> > > > 1) There is no Utypes on Windows.> > > > These are very basic types that belong at a very low level.> > > > In C++ for example, size_t is provided "automatically" by the> > > > compiler, no header is needed.> > > >> > > > 2) Are they really OS dependent? What OS makes my definitions > > wrong?> > > > On what 32 bit architecture is size_t not an unsigned 32 bit> > > > integer and ptrdiff_t not a signed 32 bit integer?> > > > Ditto for 64 bit.> > > > These should always be the same size as a pointer and with the> > > > proper signedness.> > > > Even if some of the *.i3 files make size_t = int, is that really> > > > correct?> > > > And, I assume int vs. long issue is not an issue here.> > > > Though they may be different types in C and C++, they need not be> > > > in Modula-3 (when they are the same size, of course)> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] size_t?> > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > >> > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > > >> > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > size_t => > > > > > INTEGER;> > > > > >> > > > > > really? it is signed?> > > > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > > > >> > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > > > That has a 32 bit and 64 bit version, at least.> > > > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > > >> > > > > >> > > > > >> > > > > > Does INTEGER effectively equal int or ptrdiff_t?> > > > > >> > > > > > - Jay> > > >> > > > Need to know the score, the latest news, or you need your > > Hotmail?-> > > > get your "fix". Check it out.> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 02:21:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:21:24 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86. __clrcall sort of doesn't count. It really must means "managed code", using the only calling convention available. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Feb 12 02:29:12 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:29:12 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47AF72B5.2080308@wichita.edu> References: <47AF72B5.2080308@wichita.edu> Message-ID: The liberalised alignment rules are required for the native Mac OS X API and should stay. You cannot use that API without them. I think the pragma is not required and can be removed. I agree with all the points you make. The effect of the modified alignment rules it to allow *packed* structures to have members aligned on byte boundaries. This has the effect of packing the fields in the tightest arrangement allowed by the platform. This might affect performance, but if the user is concerned about this they should specify field bit sizes that deliver improved performance. I don't see a need to specify this on a structure level, for the reasons you give and because the difference isn't significant enough in the case of packed structures and their physical layout and restrictions are platform dependent anyway. I might also add that the alignment code is currently broken on I386_DARWIN. - Darko On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > Does anybody know about the status of pragma <*LAZYALIGN*>? Is it > being used anywhere? > > It is not documented in pragmas.html. The compiler front end appears > to accept it. (In fact, Decls.m3 contains constants that suggest > limitations on what declarations the pragma can appear on, but these > are not actually enforced.) It liberalizes the alignment rules, > generally allowing scalars to start on any byte boundary. > > Pickles have to be able to reconstruct the layout of types as the > compiler would have done it for a machine (on which a now-being-read > pickle was written) with different word size and alignment properties. > Currently, pickles are completely unaware of lazy alignment. It > would have to be encoded in type descriptions generated by the > compiler > using TipeDesc and read by pickles using RTTipe. > > Most troubling to me is what looks like a linguistic Pandora's box. > The pragma can be associated with any constant, variable, or type > _declaration_ (not type definition), with the result that different > values of the same type can actually be different in their alignment > rules and thus their layout. Similarly for different identifiers > equated to the same type. Although the effects of this could possibly > be hidden from the programmer in purely safe code, not so with unsafe > code. I haven't thoroughly thought this through, but seems to me to > really fly in the face of the whole typing philosophy of the language. > > For example, if pickles were to read in an object value, and there > were >1 variants of the object's type in the reading program, > differing > only in the alignment rules, how would it decide which one to build? > In fact, ignoring pickles altogether and just looking at a single > program, > if the object's type doesn't actually uniquely give its memory layout, > how can it be accessed correctly? > > Additionally, a quick look at the compiler suggests it won't generate > correct code for whole record assignment when the LHS and RHS are the > same type but have different alignment characteristics. > > The more I think about it, it seems the only workable possibilities > are: > > 1) Require the pragma to be associated only with a type _definition_ > not a > declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > this a > property of the type that propagates to all names for the type and > all variables, constants, etc. Also, this would make this property > a part of the type signature that pickles uses when reading, -OR- > > 2) Forget it altogether. > > What do people think? > -- > ------------------------------------------------------------- > 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 darko at darko.org Tue Feb 12 02:37:49 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:37:49 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> I think it's not a good idea. I think all platform specific code should be in a separate file. I'd also like to see an option to move calling conventions to the makefile rather than in pramas to avoid having to duplicate interface files just to have a different calling convention for a different platform. - Darko On 12/02/2008, at 12:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew > more lower level details and playing games with calling conventions > was something anyone could do. Most other current systems are rooted > in C programming. Working in C, calling conventions are generally in > a hidden layer below what anyone thinks about. Therefore, the > smaller number of capable people working at that level have the good > sense to only have one calling convention. No more systems will > evolve from "small", at least not without having observed this > history. Therefore, there will no longer be multiple calling > conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:07:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:07:04 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So, here's the thing about pragmas. According to the language definition, they can be ignored and the program should still "mean" the same thing. Preprocessing definitely does not fit that model. On Feb 11, 2008, at 8:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc > directory and bringing up ignoring WINAPI on non-NT386 or prefixing > calling conventions with a target. > > This reminds me of an important point here however -- nobody else > is going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from > "small" systems, where assembly programming was common, more people > knew more lower level details and playing games with calling > conventions was something anyone could do. Most other current > systems are rooted in C programming. Working in C, calling > conventions are generally in a hidden layer below what anyone > thinks about. Therefore, the smaller number of capable people > working at that level have the good sense to only have one calling > convention. No more systems will evolve from "small", at least not > without having observed this history. Therefore, there will no > longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:08:27 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:27 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <65396937-761B-4CA3-A20F-A04D53FAA6D2@cs.purdue.edu> C and Modula-3 fill different needs. I use C when it makes sense. I use Modula-3 when it makes sense. I'd hate to blur the distinction between them though! On Feb 11, 2008, at 8:05 PM, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. > That is good. Each header exposes certain names and few names are > exposed by more than one header. As well, for good measure, your > own #includes of ANSI C headers I believe is speced as order- > independent. These are all aspects of a "good module system", > except this solid foundation is built on a foundation of quicksand > and there is inadequate support for it in the language -- i.e. no > static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from > multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must > define it (directly or indirectly). > Malloc takes size_t, so #include must define it > (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing > all of stddef.h however. > IF NOT, then there must be some underlying implementation defined > layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is > probably usually a bad idea, but it can also be darn convenient. > Just #include everything, and have everything available in the > global namespace. > The "language" does live in this space. INTEGER is ALWAYS available > and always has the same meaning (per-target). I cannot redefine it > (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this > direction. > It breaks "modularity" and so should be done very selectively, but / > arguably/ size_t and ptrdiff_t are fundamental enough to warrant > such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be > in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on > all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? > > Really, I'm sure you have all figured out, I want Modula-3 to look > more like C. :) > The more I use C lately (as opposed to C++) and the more I use > Modula-3 lately..the more I find C perfectly ok, the unsafety easy > enough to not be bitten by, the more the heap allocations and > copying that "safety" cost seem not worth it.. > > It's an interesting system largely just because it is yet another > system, in need (arguably) of more targets, and where "NT386" > exists but gets little support. Someone who "likes" Modula-3 more > would serve it better than me, perhaps. But I'm here. :) > > I also like that a decent module system was worked out such as to > build fast, at least when using the integrated backend. > So maybe I just write all my Modula-3 as "unsafe" and be happy. :) > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 18:37:56 -0500 > > To: jayk123 at hotmail.com > > > > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. > > > > Subtracting two pointers yields ptrdiff_t, so in M3 it would > > presumably be INTEGER. > > size_t is what sizeof returns, so I imagine size_t=CARDINAL is > > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > > better be Word.T to match C's unsigned interpretation. Of course, > > Word.T is simply INTEGER anyway in the current CM3 implementation. > > Note that neither of these need to be defined in the 32bit/64bit > > subdirectories since they are straightforwardly the same as the > > underlying word size. > > > > On Feb 11, 2008, at 5:34 PM, Jay wrote: > > > > > I did later notice size_t was there. > > > I think what I earlier noticed was ptrdiff_t nowhere. > > > > > > > size_t = INTEGER. > > > > > > But unsigned presumably? > > > > > > What I had was correct, right? > > > In C++ no header is needed for size_t, it is just so basic and > > > widespread. > > > Not sure about ptrdiff_t. > > > > > > Either way, they both do live in that middle ground between > > > compiler and library -- a very low level -- > > > as size_t is defined as the type of sizeof() expressions and > > > ptrdiff_t is defined as the type you get when you subtract > > > pointers. And you don't need nay header to use sizeof() or > subtract > > > pointers. > > > > > > If it were really up to me, I'd have the Modula-3 language > > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > > > There is a corralary dilemna here that I haven't figured out, and > > > have seen code address that I haven't adjusted to yet. That is, > the > > > code uses uint32 "everywhere", instead of something "more > abstract/ > > > vague". When it comes down to it, I suspect this is the right > > > thing. The abstraction only seems to buy problems. UNLESS you have > > > a processor with a larger natural integer that performs poorly on > > > smaller integers, or a processor that perfs badly with 32 bit > > > integers. > > > > > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > > > In many and growing systems, "int", besides its signedness, is too > > > small for many occurences. > > > That is the problem I think in C. If Modula-3 has essentially > > > defined INTEGER to be the size of a pointer, then ok. > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Sorry. > > > > > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > > > stick to the C ".h" structure. > > > > > > > > size_t = INTEGER. > > > > > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > 1) There is no Utypes on Windows. > > > > > These are very basic types that belong at a very low level. > > > > > In C++ for example, size_t is provided "automatically" by the > > > > > compiler, no header is needed. > > > > > > > > > > 2) Are they really OS dependent? What OS makes my definitions > > > wrong? > > > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > > > integer and ptrdiff_t not a signed 32 bit integer? > > > > > Ditto for 64 bit. > > > > > These should always be the same size as a pointer and with the > > > > > proper signedness. > > > > > Even if some of the *.i3 files make size_t = int, is that > really > > > > > correct? > > > > > And, I assume int vs. long issue is not an issue here. > > > > > Though they may be different types in C and C++, they need > not be > > > > > in Modula-3 (when they are the same size, of course) > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: [M3devel] size_t? > > > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > > size_t = > > > > > > > INTEGER; > > > > > > > > > > > > > > really? it is signed? > > > > > > > and we are sure this is going to be 64 bits on 64 bit > targets? > > > > > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > > > > > - Jay > > > > > > > > > > Need to know the score, the latest news, or you need your > > > Hotmail?- > > > > > get your "fix". Check it out. > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Tue Feb 12 03:08:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:46 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> Message-ID: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Indeed! On Feb 11, 2008, at 8:37 PM, Darko wrote: > I think it's not a good idea. I think all platform specific code > should be in a separate file. I'd also like to see an option to > move calling conventions to the makefile rather than in pramas to > avoid having to duplicate interface files just to have a different > calling convention for a different platform. > > - Darko > > > On 12/02/2008, at 12:21 PM, Jay wrote: > >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, >> or an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in >> an interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, >> just sending out the bait... >> >> Obviously this was triggered by my happening into the odbc >> directory and bringing up ignoring WINAPI on non-NT386 or >> prefixing calling conventions with a target. >> >> This reminds me of an important point here however -- nobody else >> is going to make the mistake of ever having multiple calling >> conventions. Therefore the generality of prefixing WINAPI with >> NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from >> "small" systems, where assembly programming was common, more >> people knew more lower level details and playing games with >> calling conventions was something anyone could do. Most other >> current systems are rooted in C programming. Working in C, calling >> conventions are generally in a hidden layer below what anyone >> thinks about. Therefore, the smaller number of capable people >> working at that level have the good sense to only have one calling >> convention. No more systems will evolve from "small", at least not >> without having observed this history. Therefore, there will no >> longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 From rodney.bates at wichita.edu Tue Feb 12 05:17:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 11 Feb 2008 22:17:13 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: <47B11DC9.1040902@wichita.edu> I don't think this is what Tony meant. In C++, an opening brace starts a block, but every local declaration in that block has its own unique scope that only starts at that declaration and goes to the end of the block. This is particularly messy because the local declarations of a block need not all precede all the statements, and even worse because the distinction between declarations and statements is extremely subtle and, unless things have changed, never actually defined. (Do you remember Stroustrup's famous quote when taken to task about this? "If it looks like a declaration, it's a declaration. If it looks like a statement, it's a statement. If it doesn't look like either, it's a syntax error.") In contrast, in Modula-3, the scope of every local declaration starts at the beginning of the block and ends at the end of the block. The C++ reference makes an attempt at defining different terms for the entire block and the region where the identifier can be referred-to, i.e., from declaration to end of block (which I have called "scope" here). But as I recall, they ended up carefully defining their terminology in one section but then not using it consistently in the rest of the language definition. One of the few things Ada did better than Modula-3 was that the syntax has an explicit delimiter at all three relevant points: beginning of block, between declarations and statements, and end of block. (But it still has C++-like scopes for every declaration>.) I am an adamant believer in a high level of syntactic explicitness. Ada Modula-3 C++ start of block: DECLARE { between decls and stmts: BEGIN BEGIN end of block: END END } Jay wrote: > If you want a precise scope in C++, just but in an opening brace. > Just like how in Modula-3 (now I know) you can have "BEGIN" almost > anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. > It isn't often used though, granted. > > - Jay > > ------------------------------------------------------------------------ > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] introducing VAR in more places? > > Date: Mon, 11 Feb 2008 11:34:54 -0500 > > To: jayk123 at hotmail.com > > > > You can, except you need to explicitly give the block scope: > > > > VAR ... > > BEGIN > > ... > > END; > > > > I find this much better than C++ where the scope of the new variable > > is imprecisely defined. > > > > On Feb 11, 2008, at 4:29 AM, Jay wrote: > > > > > Does anyone else find it bothersome that you can't introduce VARs > > > anywhere? Kind of like in C++? > > > Ok, or if you grant that frame size doesn't matter THAT much, and > > > the compiler might do stack packing anyway, you can move all your > > > locals up top like typical C, but still, how about for the module > > > initializer? > > > Still it seems good to me to do manual stack packing since it is > > > often so easy.. > > > WITH helps, but only for "relative constants". > > > > > > It would be nice if the code below could have still loops until t0 ! > > > = t1, but the repeat condition is outside the scope in which t1 is > > > available. This feels quite lame.. > > > > > > - Jay > > > > > > > > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > > To: m3commit at elegosoft.com > > > > From: jkrell at elego.de > > > > Subject: [M3commit] CVS Update: cm3 > > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > > > Modified files: > > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message: > > > > no need for globals here.. > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > ------------------------------------------------------------------------ > Connect and share in new ways with Windows Live. Get it now! > -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Tue Feb 12 05:10:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:10:20 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <427855DD-C178-414E-8AEC-3BB723699B87@cs.purdue.edu> Score a big win for the regression test framework! I would not have devoted the time to finding the recently fixed race condition for mutex/condition initialization in the pthreads-based thread implementation if I had not been told about the problem with p007 on FreeBSD4. The problem only revealed itself in a repeatable way on FreeBSD4, and not repeatably enough to be debuggable on all the other systems I use (I386_DARWIN, PPC_DARWIN, LINUXLIBC6, or Solaris -- except for a clue in an error report from Alex Bochanek). Regression testing on multiple platforms is practically the only way to shake out these sorts of insidious bugs. Yay! Good work guys! On Jan 31, 2008, at 6:43 AM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression >> testing >> would help and should be introduced. Tests should be run daily/ >> nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these >> services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for > others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be > transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a > FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of > course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to > participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh > cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment > this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox /usr/ > local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue Feb 12 05:27:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:27:35 -0500 Subject: [M3devel] scripts/PKGS Message-ID: I notice scripts/PKGS is no longer in the repository. Does this get generated somehow now? I know that do-cm3-std.sh depends on it because my copy of PKGS was broken (missing sysutils). Can someone explain to me how the build scripts have changed and how I should be using them? From darko at darko.org Tue Feb 12 05:37:52 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 15:37:52 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B1168F.8020302@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> Message-ID: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for historical reasons. All other structures should use normal alignment to be compatible with C and Unix interfaces. The alignment change was implemented to be supported only in packed structures as a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly restrictive alignment rules in packed structures. On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > It sounds like all that Mac OS X needs is for _all_ types in an entire > program to use the liberal packing rules. Have I understood > correctly? > I would have no grief over that. > > Darko wrote: >> The liberalised alignment rules are required for the native Mac OS >> X API and should stay. You cannot use that API without them. I >> think the pragma is not required and can be removed. I agree with >> all the points you make. The effect of the modified alignment >> rules it to allow *packed* structures to have members aligned on >> byte boundaries. This has the effect of packing the fields in the >> tightest arrangement allowed by the platform. This might affect >> performance, but if the user is concerned about this they should >> specify field bit sizes that deliver improved performance. I don't >> see a need to specify this on a structure level, for the reasons >> you give and because the difference isn't significant enough in >> the case of packed structures and their physical layout and >> restrictions are platform dependent anyway. >> I might also add that the alignment code is currently broken on >> I386_DARWIN. >> - Darko >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>> being used anywhere? >>> >>> It is not documented in pragmas.html. The compiler front end >>> appears >>> to accept it. (In fact, Decls.m3 contains constants that suggest >>> limitations on what declarations the pragma can appear on, but these >>> are not actually enforced.) It liberalizes the alignment rules, >>> generally allowing scalars to start on any byte boundary. >>> >>> Pickles have to be able to reconstruct the layout of types as the >>> compiler would have done it for a machine (on which a now-being-read >>> pickle was written) with different word size and alignment >>> properties. >>> Currently, pickles are completely unaware of lazy alignment. It >>> would have to be encoded in type descriptions generated by the >>> compiler >>> using TipeDesc and read by pickles using RTTipe. >>> >>> Most troubling to me is what looks like a linguistic Pandora's box. >>> The pragma can be associated with any constant, variable, or type >>> _declaration_ (not type definition), with the result that different >>> values of the same type can actually be different in their alignment >>> rules and thus their layout. Similarly for different identifiers >>> equated to the same type. Although the effects of this could >>> possibly >>> be hidden from the programmer in purely safe code, not so with >>> unsafe >>> code. I haven't thoroughly thought this through, but seems to me >>> to >>> really fly in the face of the whole typing philosophy of the >>> language. >>> >>> For example, if pickles were to read in an object value, and there >>> were >1 variants of the object's type in the reading program, >>> differing >>> only in the alignment rules, how would it decide which one to build? >>> In fact, ignoring pickles altogether and just looking at a single >>> program, >>> if the object's type doesn't actually uniquely give its memory >>> layout, >>> how can it be accessed correctly? >>> >>> Additionally, a quick look at the compiler suggests it won't >>> generate >>> correct code for whole record assignment when the LHS and RHS are >>> the >>> same type but have different alignment characteristics. >>> >>> The more I think about it, it seems the only workable >>> possibilities are: >>> >>> 1) Require the pragma to be associated only with a type >>> _definition_ not a >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>> this a >>> property of the type that propagates to all names for the type and >>> all variables, constants, etc. Also, this would make this property >>> a part of the type signature that pickles uses when reading, -OR- >>> >>> 2) Forget it altogether. >>> >>> What do people think? >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 hendrik at topoi.pooq.com Tue Feb 12 05:35:55 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:35:55 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <20080212043555.GA21429@topoi.pooq.com> On Tue, Feb 12, 2008 at 01:05:39AM +0000, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must define it (directly or indirectly). > Malloc takes size_t, so #include must define it (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. > IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. > The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this direction. > It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? The real requirement on size_t is that values of that type can be used freely in address arithmetic. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:38:21 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:38:21 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080212043821.GB21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:03:22PM +0000, Jay wrote: > Tony, is /everything/ Win32 ugly? :) No. Some of the video games are breathtakingly beautiful. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:39:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:39:29 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: <20080212043929.GC21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 09:52:06PM +0000, Jay wrote: > I guess I should switch the default calling convention and see what > the code size difference is. > Yes. Code size can be neasured. -- hendrik From jayk123 at hotmail.com Tue Feb 12 07:16:45 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:16:45 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: It is generated if it doesn't exist. Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them?> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:18:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:18:01 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: <20080212042047.A12E210D4686@birch.elegosoft.com> References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I added some files a while ago and someone either complained or added them, so I've been adding them since. - Jay > Date: Tue, 12 Feb 2008 05:20:47 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:20:47> > Modified files:> cm3/m3-sys/cm3/src/: m3makefile > > Log message:> Let's avoid RCS id stuff shall we. Just clutters up the files...> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:22:28 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:22:28 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available. There is/was a compilation problem with what I was doing. I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 08:20:33 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 07:20:33 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: This is not my doing, at least not knowingly, just reporting the facts, officer. I wonder if maybe something more like Randy's scheme should be put in place. He has a smaller hand authored checked in file. The current system is more automatic, but doesn't handle changes automatically, and generates far more data than necessary I think. Perhaps another approach is to keep a timestamp/revision, embedded in the name, pkgs.v1234, someone rev the name as needed, and if the desired name doesn't exist rm pkgs.v* and recreate? This is a nice simple model imho. Changes are also very infrequent in my short observance. (I do go so far in the python directory to always use forward slashes, so the files are more portable across systems. :) Really, you know, it doesn't matter what the underlying system uses, as long as you translate at all the appropriate places and as long as you pick a syntax that can represent everything needed (not necessarily anything the underlying system supports). However you do have to translate at all the appropriate levels, possibly under the guidance of user settings. In particular, I can set M3CONFIG, M3ROOT, etc. to have forward slashes and it works just fine on Windows, but when errors are reported with paths, I can't paste them into file.open dialogs without changing the slashes....) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 06:16:45 +0000Subject: Re: [M3devel] scripts/PKGS It is generated if it doesn't exist.Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them? _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 09:16:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 09:16:42 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken Message-ID: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Tonight some of the tinderbox builds failed for CM3. First I thought it was just these changes to FilePosix which had already been fixed: ---------------------------- revision 1.8 date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: +1 -1; commitid: pvCLLyqdDKQm24Rs; This checkin fixes something Jay left behind. Please check things build on platforms other than yours before making changes. The VAL is necessary on some targets because 0 is INTEGER whereas result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly compared with an INTEGER (result). The VAL is how we do the conversion to LONGINT. On platforms where Utypes.off_t is INTEGER this code will work the same as it is. ---------------------------- revision 1.7 date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: +1 -1; commitid: j3ewJLumr87rqWQs; more cygwin header cleanup, various dead types were used in further dead types in Ushm.i3; go ahead and delete dead stuff instead of commenting out remove seemingly unnecessary VAL() that fails to compile but when I try to build now on my FreeBSD system, I get this from cm3: % ./m3-sys/cm3/FreeBSD4/cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 *** ^C Please check all the latest commits carefully and back out anything that seems suspicious or has not been tested. Thanks, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Feb 12 09:27:40 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:27:40 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: drat...I'd like to punt just a few hours here and will get to it then. Sorry. I hardly changed anything "live" other than what Tony put back. Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 09:45:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:45:24 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: The only other non-NT386/GNU change by me, from a quick scan of ChangeLog, is: 2008-02-10 23:24 jkrell * m3-libs/m3core/src/: runtime/m3makefile, thread/m3makefile, thread/Common/SchedulerPosix.i3, thread/Common/m3makefile, thread/POSIX/SchedulerPosix.i3, thread/POSIX/m3makefile, thread/PTHREAD/SchedulerPosix.i3, thread/PTHREAD/m3makefile, thread/WIN32/ThreadWin32.m3: cheat just a tad and provide SchedulePosix interface on Win32 albeit not a good implementation currently this way NT386GNU can build with Win32 threads and cm3 gets as far as printing an error and exiting, probably something to do with pesky slashes; a lot better than hanging due to nanosleep failing and worrying about a lot of non trivial cygwin code.. which looks very ok. I moved SchedulerPosix to common and provided a do-nothing implementation for NT386. This is so NT386GNU can use native Win32 threads, but Posix in other places like i/o. (Sometimes I wonder...maybe all that's needed is handling forward and backward slashes the same c:/foo/bar, which I already put in, plus allowing X Windows... (Trestle builds now btw...std packages get at least as far as anim3d. Running stuff is known to have problems..the slash issues were just because I had backslashes (and colons) in paths in environment variables... the current problem is that cm3 always seems to think files are out of date and that all builds fail, but it does actually run cm3cg over everything and seems to work...surely an easy issue to deal with...oh I think m3bundle crashes, the only other thing I've run besides cm3...like..for example, keeping time in seconds since 1970 in a 32bit signed integer seems more like a bug than a feature....maybe I'll start another thread here....even the Win32 Modula-3 interfaces I think use that poor representation, just that they go to the effort of converting from a better format....)) Anyway I'll at least test on birch later and maybe install FreeBSD in a virtual machine..... - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 08:27:40 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken drat...I'd like to punt just a few hours here and will get to it then.Sorry.I hardly changed anything "live" other than what Tony put back.Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 11:34:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 11:34:42 +0100 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Quoting Tony Hosking : > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it because > my copy of PKGS was broken (missing sysutils). Can someone explain to > me how the build scripts have changed and how I should be using them? PKGS has never been checked-in and should not as far as I know. It contains workspace-dependent paths and is built by find-packages.sh if I remember correctly. All shell scripts will generate it if it does not exist. It can be deleted any time, and indeed must be deleted if packages are added (or they will not be found). This is arguably a bug, but then all the scripts were never intended to be a general user interface for CM3 users (only for the maintenance). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Tue Feb 12 12:23:21 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:23:21 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: Obviously if the paths are relative to CM3_ROOT, it isn't workspace dependent... How about my idea of making the name have a "version" in it, and the version can be bumped as needed? Or making it contain relative paths and just maintain it manually? - Jay > Date: Tue, 12 Feb 2008 11:34:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] scripts/PKGS> > Quoting Tony Hosking :> > > I notice scripts/PKGS is no longer in the repository. Does this get> > generated somehow now? I know that do-cm3-std.sh depends on it because> > my copy of PKGS was broken (missing sysutils). Can someone explain to> > me how the build scripts have changed and how I should be using them?> > PKGS has never been checked-in and should not as far as I know.> It contains workspace-dependent paths and is built by find-packages.sh> if I remember correctly. All shell scripts will generate it if it> does not exist. It can be deleted any time, and indeed must be deleted> if packages are added (or they will not be found). This is arguably a bug,> but then all the scripts were never intended to be a general user interface> for CM3 users (only for the maintenance).> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:34:08 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:34:08 +0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: I strongly suggest that at least in some contexts, no padding ever be quietly inserted, and that all seeming need for padding generate an error, unless explicitly quashed, preferably by explicit insertion of padding fields by the programmer, and/or rearrangement sorted by size, or possibly some annotation of the overall struct/record/class/module, an annotation such as <* silent padding ok*>. Alignment issues really bug me... I realize many data structures are only ever seen in memory, by one process, so it doesn't matter, but when it matter, the languages/tools seem to fall down. As well, "padding" fields should be annotated as such and the compiler warn or error if they aren't needed. It's just dumb that code like: struct { int32 a; int64 b;}; when defining some stable important binary layout can have a varying but silently allowed meaning based on command line switches or targets.. Yes, I'm a dumb programmer to write it, but man the tools are lagging. This will fall on deaf ears and far from sufficient ears even if they were hearing. It's the C compilers that are somewhat broken here imho. C is unnecessarily broken here. Imho it's a big cause for headaches and easily solved....it doesn't have to stink so badly, if anyone cared.. I have had to maintain structs that had to look the same across different targets and therefore insert target-dependent padding. Ok, but it should have been easier. When I was done, I put in compile time asserts as to the offset of every single field so the next guy would have an easier time, and assiduously commented every byte of padding in the struct and its target-dependentness.... This was like for shared memory. Grumble, - Jay > From: darko at darko.org> To: rodney.bates at wichita.edu> Date: Tue, 12 Feb 2008 15:37:52 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] <*LAZYALIGN*>> > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures.> > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:> > > It sounds like all that Mac OS X needs is for _all_ types in an entire> > program to use the liberal packing rules. Have I understood > > correctly?> > I would have no grief over that.> >> > Darko wrote:> >> The liberalised alignment rules are required for the native Mac OS > >> X API and should stay. You cannot use that API without them. I > >> think the pragma is not required and can be removed. I agree with > >> all the points you make. The effect of the modified alignment > >> rules it to allow *packed* structures to have members aligned on > >> byte boundaries. This has the effect of packing the fields in the > >> tightest arrangement allowed by the platform. This might affect > >> performance, but if the user is concerned about this they should > >> specify field bit sizes that deliver improved performance. I don't > >> see a need to specify this on a structure level, for the reasons > >> you give and because the difference isn't significant enough in > >> the case of packed structures and their physical layout and > >> restrictions are platform dependent anyway.> >> I might also add that the alignment code is currently broken on > >> I386_DARWIN.> >> - Darko> >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote:> >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it> >>> being used anywhere?> >>>> >>> It is not documented in pragmas.html. The compiler front end > >>> appears> >>> to accept it. (In fact, Decls.m3 contains constants that suggest> >>> limitations on what declarations the pragma can appear on, but these> >>> are not actually enforced.) It liberalizes the alignment rules,> >>> generally allowing scalars to start on any byte boundary.> >>>> >>> Pickles have to be able to reconstruct the layout of types as the> >>> compiler would have done it for a machine (on which a now-being-read> >>> pickle was written) with different word size and alignment > >>> properties.> >>> Currently, pickles are completely unaware of lazy alignment. It> >>> would have to be encoded in type descriptions generated by the > >>> compiler> >>> using TipeDesc and read by pickles using RTTipe.> >>>> >>> Most troubling to me is what looks like a linguistic Pandora's box.> >>> The pragma can be associated with any constant, variable, or type> >>> _declaration_ (not type definition), with the result that different> >>> values of the same type can actually be different in their alignment> >>> rules and thus their layout. Similarly for different identifiers> >>> equated to the same type. Although the effects of this could > >>> possibly> >>> be hidden from the programmer in purely safe code, not so with > >>> unsafe> >>> code. I haven't thoroughly thought this through, but seems to me > >>> to> >>> really fly in the face of the whole typing philosophy of the > >>> language.> >>>> >>> For example, if pickles were to read in an object value, and there> >>> were >1 variants of the object's type in the reading program, > >>> differing> >>> only in the alignment rules, how would it decide which one to build?> >>> In fact, ignoring pickles altogether and just looking at a single > >>> program,> >>> if the object's type doesn't actually uniquely give its memory > >>> layout,> >>> how can it be accessed correctly?> >>>> >>> Additionally, a quick look at the compiler suggests it won't > >>> generate> >>> correct code for whole record assignment when the LHS and RHS are > >>> the> >>> same type but have different alignment characteristics.> >>>> >>> The more I think about it, it seems the only workable > >>> possibilities are:> >>>> >>> 1) Require the pragma to be associated only with a type > >>> _definition_ not a> >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > >>> this a> >>> property of the type that propagates to all names for the type and> >>> all variables, constants, etc. Also, this would make this property> >>> a part of the type signature that pickles uses when reading, -OR-> >>>> >>> 2) Forget it altogether.> >>>> >>> What do people think?> >>> -- > >>> -------------------------------------------------------------> >>> 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> >> > -- > > -------------------------------------------------------------> > 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> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:50:00 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:50:00 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Message-ID: I insist that it depends. Putting every platform-specific piece of code in its own file/directory can lead to mass duplication of nearly identical code. Sometimes an #if here or there goes very far in /improving/ code maintainability. A lot of #if here there and everywhere of course can have the opposite effect. And I realize if you were to drop support for a target, it is easier to find/delete files/directories than #ifs, but I don't think that's a good enough reason to sway the decision. It goes both ways. Yes, you could endeavor factor things down so that everything common is in common, and everything not-common is in platform-specific. But this is inadequate I think. The tail is wagging the dog unnecessarily I think. If my code very nearly all goes together, don't make me separate it. Also sometimes a different factoring is "encouraged" for other reasons, to match someone else's factoring. Look at the C*.i3 files. They actually can be almost all be nearly the same, yet they are hardly shared at all. I realize you could also do a sort of "forwarding", though I'm not sure that Modula-3 offers all the right capabilities for this. Type forwarding, sure. But how about procedure forwarding? Like nt386\cstdio.i3 fopen = common\ccommonstdio.i3 fopen? And having to duplicate a line per type/procedure is lame anyway, you KIND OF want "module inheritance". However, if you allow preprocessing based on target, perhaps the need for that goes away. While extern C varargs functions are generally useless in Modula-3, and therefore extern __cdecl is fairly rare, it DOES occur when you write little helpers in C, such as for errno. A good /heuristic/ might be to change the default in any directory that has no c_source. But it is only heuristic. Whatever is done here, some allowance should probably be made for multiple calling conventions in the same file. Switching the default to the overwhelming majority and then annotating the minority is reasonable. I still believe that silently ignoring calling conventions on all but NT386 is VERY reasonable, and that no other platform from here on out will ever have calling conventions. Esp. not with the same names. When OS/FOO has the FOOAPI calling convention, you can just ignore that one on all but target OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ugly something like: <*EXTERN FOOAPI WINAPI*> fopen(); FOOAPI for OS/FOO, WINAPI ignored. WINAPI for NT386, FOOAPI ignored. The One True Calling Convention for all others, calling convention ignored. I really believe this is highly highly unlikely to occur, and it is not a terrible outcome, and this bridge could be crossed in the far off future. The functions that are usually in need of calling conventions are usually only present on one system. Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly nonexistant. That could be also. A change just for ODBC is probably not the best, though it is a very small safe harmless change (I always say that :) ) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 2008 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform specific code > > should be in a separate file. I'd also like to see an option to > > move calling conventions to the makefile rather than in pramas to > > avoid having to duplicate interface files just to have a different > > calling convention for a different platform.> >> > - Darko> >> >> > On 12/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this through.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good > >> idea.> >>> >> Something like either the ability to prefix pragmas with a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Something like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worms.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expressions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >> etc.> >>> >> I don't really have enough interest here to work through this, > >> just sending out the bait...> >>> >> Obviously this was triggered by my happening into the odbc > >> directory and bringing up ignoring WINAPI on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> This reminds me of an important point here however -- nobody else > >> is going to make the mistake of ever having multiple calling > >> conventions. Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> >> Unless Mac68K support is added.> >>> >> And here is some rationale even. The PC and Mac evolved from > >> "small" systems, where assembly programming was common, more > >> people knew more lower level details and playing games with > >> calling conventions was something anyone could do. Most other > >> current systems are rooted in C programming. Working in C, calling > >> conventions are generally in a hidden layer below what anyone > >> thinks about. Therefore, the smaller number of capable people > >> working at that level have the good sense to only have one calling > >> convention. No more systems will evolve from "small", at least not > >> without having observed this history. Therefore, there will no > >> longer be multiple calling conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >> only x86> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 13:05:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 13:05:56 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Hi again, the builds I started again this morning before leaving home seem to have succeeded again. I don't understand why compilation with the latest sources on my own system was broken though; I'll have to check that tonight. There's seems to be no immediate need for action though :-) It would be great if all committers would check the tinderbox status on http://www.opencm3.net at least after check-ins. You'll find it under "Status -> Tinderbox Tests", or directly at http://tinderbox.elegosoft.com/tinderbox/cm3/status.html. It contains links to all the build logs and the m3tests and package build test results, as well as a list of check-ins that may be responsible for any breakage (click on the dates in the left column). Olaf Quoting Olaf Wagner : > Tonight some of the tinderbox builds failed for CM3. First I thought > it was just these changes to FilePosix which had already been fixed: > > ---------------------------- > revision 1.8 > date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: > +1 -1; commitid: pvCLLyqdDKQm24Rs; > This checkin fixes something Jay left behind. > > Please check things build on platforms other than yours before making > changes. The VAL is necessary on some targets because 0 is INTEGER whereas > result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly > compared with an INTEGER (result). The VAL is how we do the conversion to > LONGINT. > > On platforms where Utypes.off_t is INTEGER this code will work the same as it > is. > ---------------------------- > revision 1.7 > date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs; > more cygwin header cleanup, various dead types were used > in further dead types in Ushm.i3; go ahead and delete > dead stuff instead of commenting out > remove seemingly unnecessary VAL() that fails to compile > > but when I try to build now on my FreeBSD system, I get this from cm3: > > % ./m3-sys/cm3/FreeBSD4/cm3 -version > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 > *** > > ^C > > Please check all the latest commits carefully and back out anything > that seems suspicious or has not been tested. > > Thanks, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.caltech.edu Tue Feb 12 13:56:02 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 04:56:02 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." Message-ID: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Can you just generate the Modula-3 code you want using a Python script or COBOL or whatever you like instead of trying to foist preprocessing nastiness on innocent users of high-level Modula-3? Preprocessing is super nasty. It's not just a question of human readability. m3tk has to be able to read the code, too. I should be able to write a program that reads in (using m3tk) an arbitrary Modula-3 interface and understands it to the point that it can generate Network Object stubs, inter-language call stubs, etc. The stubs should ALSO be human- and m3tk-readable after the transformation! This should work even if the programmer has been very "clever" in his use of Modula-3 constructs. (Just try getting something like that to work with C or C++... it's hopeless once the preprocessor gets involved, and possibly before.) Also if I may make a little request, if at all possible, please try not to break binary compatibility with gcc-compiled C and Fortran on NT386GNU (not sure if your ideas about calling conventions could possibly do that...) Mika Jay writes: >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I insist that it depends. >Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code. >Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility. >A lot of #if here there and everywhere of course can have the opposite effe= >ct. >And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision. >It goes both ways. >=20 >Yes, you could endeavor factor things down so that everything common is in = >common, and everything not-common is in platform-specific. But this is inad= >equate I think. The tail is wagging the dog unnecessarily I think. If my co= >de very nearly all goes together, don't make me separate it. Also sometimes= > a different factoring is "encouraged" for other reasons, to match someone = >else's factoring. Look at the C*.i3 files. They actually can be almost all = >be nearly the same, yet they are hardly shared at all. I realize you could = >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >l the right capabilities for this. Type forwarding, sure. But how about pro= >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is lame anyway, you = >KIND OF want "module inheritance". However, if you allow preprocessing base= >d on target, perhaps the need for that goes away. >=20 >While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno. >=20 >A good /heuristic/ might be to change the default in any directory that has= > no c_source. >But it is only heuristic. >=20 >Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file. >Switching the default to the overwhelming majority and then annotating the = >minority is reasonable. >=20 >I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like: ><*EXTERN FOOAPI WINAPI*> fopen(); >FOOAPI for OS/FOO, WINAPI ignored. >WINAPI for NT386, FOOAPI ignored. >The One True Calling Convention for all others, calling convention ignored. >=20 >I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future. >The functions that are usually in need of calling conventions are usually o= >nly present on one system. >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant. >That could be also. >A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) ) >=20 >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e= >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20= >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:= >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform= > specific code > > should be in a separate file. I'd also like to see an op= >tion to > > move calling conventions to the makefile rather than in pramas = >to > > avoid having to duplicate interface files just to have a different >= > > calling convention for a different platform.> >> > - Darko> >> >> > On 1= >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug= >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good= > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit= >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi= >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >= >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm= >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >= > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr= >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >= >> etc.> >>> >> I don't really have enough interest here to work through thi= >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b= >y my happening into the odbc > >> directory and bringing up ignoring WINAPI= > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >This reminds me of an important point here however -- nobody else > >> is g= >oing to make the mistake of ever having multiple calling > >> conventions. = >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> = >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.= > The PC and Mac evolved from > >> "small" systems, where assembly programmi= >ng was common, more > >> people knew more lower level details and playing g= >ames with > >> calling conventions was something anyone could do. Most othe= >r > >> current systems are rooted in C programming. Working in C, calling >= > >> conventions are generally in a hidden layer below what anyone > >> thin= >ks about. Therefore, the smaller number of capable people > >> working at t= >hat level have the good sense to only have one calling > >> convention. No = >more systems will evolve from "small", at least not > >> without having obs= >erved this history. Therefore, there will no > >> longer be multiple callin= >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does= > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I insist that it depends.
>Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code.
>Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility.
>A lot of #if here there and everywhere of course can have the opposite effe= >ct.
>And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision.
>It goes both ways.
> 
>Yes, you could endeavor factor things down so that everything common i= >s in common, and everything not-common is in platform-specific. But this is= > inadequate I think. The tail is wagging the dog unnecessarily I think. If = >my code very nearly all goes together, don't make me separate it. = >;Also sometimes a different factoring is "encouraged" for other reasons, to= > match someone else's factoring. Look at the C*.i3 files. They actually can= > be almost all be nearly the same, yet they are hardly shared at all. I rea= >lize you could also do a sort of "forwarding", though I'm not sure that Mod= >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu= >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco= >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la= >me anyway, you KIND OF want "module inheritance". However, if you allow pre= >processing based on target, perhaps the need for that goes away.
> 
>While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno.
> 
>A good /heuristic/ might be to change the default in any directory that has= > no c_source.
>But it is only heuristic.
> 
>Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file.
>Switching the default to the overwhelming majority and then annotating the = >minority is reasonable.
> 
>I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like:
><*EXTERN FOOAPI WINAPI*> fopen();
>FOOAPI for OS/FOO, WINAPI ignored.
>WINAPI for NT386, FOOAPI ignored.
>The One True Calling Convention for all others, calling convention ignored.= >
> 
>I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o= >nly present on one system.
>Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant.
>That could be also.
>A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) )
> 
> 
> - Jay

> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c= >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&= >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g= >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro= >te:
>
> > I think it's not a good idea. I think all platfor= >m specific code
> > should be in a separate file. I'd also like t= >o see an option to
> > move calling conventions to the makefile r= >ather than in pramas to
> > avoid having to duplicate interface f= >iles just to have a different
> > calling convention for a differ= >ent platform.
> >
> > - Darko
> >
> >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >;> So I have NOT thought this through.
> >>
> >>= > I wonder if "preprocessing" dependent only on "target" is a good
> = >>> idea.
> >>
> >> Something like either the = >ability to prefix pragmas with a target,
> >> or an "iftarget"= > and "ifnottarget" pragma.
> >>
> >> Something like= > so:
> >>
> >> <* IF_TARGET NT386 *>
> = >>> <* END_IF_TARGET*>
> >>
> >>
>= > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*= >>
> >> It's a small can of worms.
> >> Where can= > they be placed? Only at "global" scope? (ie: toplevel in
> >>= > an interface/module).
> >>
> >> What about IF_OSTY= >PE?
> >> What about expressions?
> >> IF_TARGET NT3= >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>= >; >>
> >> etc.
> >>
> >> I don't = >really have enough interest here to work through this,
> >> ju= >st sending out the bait...
> >>
> >> Obviously this= > was triggered by my happening into the odbc
> >> directory an= >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c= >alling conventions with a target.
> >>
> >> This re= >minds me of an important point here however -- nobody else
> >>= >; is going to make the mistake of ever having multiple calling
> >= >;> conventions. Therefore the generality of prefixing WINAPI with
&g= >t; >> NT386: is useless.
> >> Unless Mac68K support is ad= >ded.
> >>
> >> And here is some rationale even. The= > PC and Mac evolved from
> >> "small" systems, where assembly = >programming was common, more
> >> people knew more lower level= > details and playing games with
> >> calling conventions was s= >omething anyone could do. Most other
> >> current systems are = >rooted in C programming. Working in C, calling
> >> convention= >s are generally in a hidden layer below what anyone
> >> think= >s about. Therefore, the smaller number of capable people
> >> = >working at that level have the good sense to only have one calling
>= > >> convention. No more systems will evolve from "small", at least no= >t
> >> without having observed this history. Therefore, there = >will no
> >> longer be multiple calling conventions.
> &= >gt;>
> >> That is my theory at least.
> >>
&g= >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall= > is
> >> only x86
>


Climb to the top= > of the charts!=A0Play the word scramble challenge with star power. =3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin= >k_jan' target=3D'_new'>Play now! >= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- From jayk123 at hotmail.com Tue Feb 12 14:18:18 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:18:18 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika, I'm not going to change the default calling convention. Don't worry. At "best", try it out, measure it, and then provide pragmas/command line switches if folks want largescale change, but never by default, and even command line switch could be dangerous..the safe form is it'd only affect implemented implementation in a directory with a particular m3makefile directive, it would not affect imported implementations. And this is way way way down any nonexistant list.. Probably more interesting than more efficient but "canonical" calling conventions is "whole program optimization" like cross "module (source file) inlining, custom calling conventions, cross function constant propagation, etc. Stuff all left to gcc. :) Moving to AMD64 will make this go away quite nicely. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:23:26 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:23:26 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <47B11DC9.1040902@wichita.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> <47B11DC9.1040902@wichita.edu> Message-ID: <20080212132326.GA22149@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > I don't think this is what Tony meant. In C++, an opening brace > starts a block, but every local declaration in that block has its own > unique scope that only starts at that declaration and goes to the end > of the block. This is particularly messy because the local declarations > of a block need not all precede all the statements, That is, in my opinion, one of the few things that C and C++ did right, well, almost right. It permits a coding style in which every variable declaration is initialised, and is declared if and only if it has a value. Now that's a useful property. It fails for recursion, so there are limits in how far it can apply. And when coding like this, you want the simplest syntax to define a constant identifier -- one whose value cannot be rebound except by reexecuting the entire block. Making something that can change should require more effort -- like adding a keyword "var" or some such. It's amazing how many identifiers end up fitting this constraint, yielding very little visual ambiguity as to whether the value of a variable has changed since initialisation. This tends to be the style in functional languages. In my opinion, functional-style languages would benefit from detailed static typing (as detailed as Modula 3) and some imperative features, like assignment to things that are explicitly declared as being variable. While rarely needed (but usually at least a few times per program), doing completely without imperative features I consider an exercise in masochism. But I can't see any way that this would fit seamlessly into Modula 3 syntax. -- hendrik > and even worse > because the distinction between declarations and statements is extremely > subtle and, unless things have changed, never actually defined. > > (Do you remember Stroustrup's famous quote when taken to task about this? > "If it looks like a declaration, it's a declaration. If it looks like a > statement, it's a statement. If it doesn't look like either, it's a > syntax error.") Last time I looked at it (when I was involved in a C++ implementation a decade or more ago) the rule was "If it looks like a declaration, it's a declaration; *otherwise* if it looks like a statement, it's a statement.", with precise constraints on what contextual information the compiler was allowed to look at when deciding what it looked like. The only correct way I found to implement this was to parse every statement-declaration-like thing first as a declaration, and, if that failed, as a statement. It was a mess. -- hendrik > In contrast, in Modula-3, the scope of every local declaration > starts at the beginning of the block and ends at the end of the > block. A simple rule, but, in my opinion, a little too simple. > > The C++ reference makes an attempt at defining different terms for the > entire block and the region where the identifier can be referred-to, i.e., > from declaration to end of block (which I have called "scope" here). > But as I recall, they ended up carefully defining their terminology in > one section but then not using it consistently in the rest of the > language definition. Their heart wasn't really into it, was it? Much rather let the implementation define the language. -- hendrik From mika at async.caltech.edu Tue Feb 12 14:41:31 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 05:41:31 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> Message-ID: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: >> I don't think this is what Tony meant. In C++, an opening brace >> starts a block, but every local declaration in that block has its own >> unique scope that only starts at that declaration and goes to the end >> of the block. This is particularly messy because the local declarations >> of a block need not all precede all the statements, > >That is, in my opinion, one of the few things that C and C++ did right, >well, almost right. It permits a coding style in which every >variable declaration is initialised, and is declared if and only if it You can do all kinds of fun stuff with C's declarations/initializations. switch (a) { int x=7; case 0: use(x); /* oops */ ... } goto somewherefun; { int y=7; somewherefun: use(y); /* oops again */ } >has a value. Now that's a useful property. It fails for recursion, >so there are limits in how far it can apply. And when coding like this, >you want the simplest syntax to define a constant identifier -- one >whose value cannot be rebound except by reexecuting the entire block. >Making something that can change should require more effort -- like >adding a keyword "var" or some such. Sounds to me like you're talking about Modula-3's WITH! Mika From jayk123 at hotmail.com Tue Feb 12 14:50:22 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:50:22 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika good point, I know that, forgot, thanks for reminding me. One of the interesting things about Modula-3, or rather anything but C and C++, is easy parsing, easy building of other tools. Just to be clear though, independent of my crazy ideas, such tools can't just enumerate a source tree. I guess they should operate over the pkg tree? You know, they can't understand the source tree without understanding m3makefiles. I started a little experiment here. I added m3-libs/m3core/src/C/common/Cstdio.i3. This is a file that ought to be nearly identical for all targets. For now I only changed NT386. I'm thinking either: a) I'm not quite on base and just fork it per-target, as it was b) provide a little bit of C code with #ifdefs, like making the SEEK_* constants into VARs and using C to initialize them. That's a bit of a downer though, since constants ought to be constants. c) factor it somehow as I was alluding, like, well, again I'm not sure Modula-3 has what I'd want here, but at least for types and constants, you can push the non-portable stuff into Ctargetstdio.i3 and then expose them in Cstdio.i3, forking only Ctargetstdio.i. I'll explain so I can get my question in. :) I understand, say: Ctargetstdio.i3 (* one of these per target, with not much content *) CONST SEEK_CUR = ..; (* target specific probably *) SEEK_SET = ..; ditto SEEK_END = ..; ditto TYPE FOO = ... ditto Cstdio.i3 (* portable *) CONST SEEK_CUR = Ctargetstdio.SEEK_CUR; SEEK_SET = Ctargetstdio.SEEK_SET; SEEK_END = Ctargetstdio.SEEK_END; TYPE FOO = Ctargetstdio.FOO; FILE = UNTRACED REF RECORD END; procedure fopen(a: const_char_star; b: const_char_star): FILE; It is tedious but I believe it works. It'd be nice, I think, if every symbol in one interface could be automatically aliases/exposed in another. At least for this purpose, maybe not for any other. I'm speculating here, so please respond kindly. :) The non portable types and constants can be pushed out and then reexposed as if they were portable and in one place. However, let's say, for argument/question's sake, that some function accepts int on some targets, off_t on another. Nevermind for now how you can portably call it. Ctargetstdio.i3 (* one of these for every target, but another question in a sec ... *) PROCEDURE seeksomething(a: off_t); let's say it is int on some platforms. Cstdio.i3 (* the portable one *) seeksomething = Ctargetstdio.seeksomething; does this work? I should try it out, read the docs. But then the next question would be, let's say there's 20 platforms and 5 use off_t and 15 use int. It's unfortunate if I have to repeat the content 20 times when there are only two variants. You can see this kind of thing where sometimes we include_dir(TARGET), sometimes include_dir(OS_TYPE). OS_TYPE implies less work, nice. Perhaps concatening stuff in arbitrary way with Quake really is the way? It seems almost sarcastic, but perhaps not. As long as the pkg store is easily parsed? (There's a setting to ship implementation files. I guess that must be left on? I thought it'd be nice to reduce distribution size..) But for that matter --- could be processed by the compiler and result in a file with it already accounted for and ship that. Isn't that just as good? EXCEPT that more thought would have to go into the spec, whereas m3makefile is already a general purpose system that anyone can do anything with? ?? - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:52:05 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:52:05 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <20080212135205.GC22149@topoi.pooq.com> On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > >> I don't think this is what Tony meant. In C++, an opening brace > >> starts a block, but every local declaration in that block has its own > >> unique scope that only starts at that declaration and goes to the end > >> of the block. This is particularly messy because the local declarations > >> of a block need not all precede all the statements, > > > >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations. > > switch (a) { > int x=7; > case 0: > use(x); /* oops */ > ... > } > > goto somewherefun; > > { > int y=7; > > somewherefun: > use(y); /* oops again */ > } That's more a problem with C's control structures. Each case should be a block of its own. The bits outside any case shouldn't be there. etc., etc. > > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such. > > Sounds to me like you're talking about Modula-3's WITH! Close, except for syntax. If you use WITH in the stype I'm advocating you end up with extremely deep syntactic nesting, and you indent off the side of the page. Also, the whole WITH syntax is quite heavy. -- hendrik From jayk123 at hotmail.com Tue Feb 12 15:02:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:02:23 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: C++ fixes this sort of thing. goto around initialization is an error. C++ constructors and destructors are a really good thing -- can't forgot to initialize or cleanup stuff. Very much like try/finally, but the finally code is better "positioned". Rather than special case memory with some fancy garbage collector, provide a mechanism for any type. RAII and all that. It's a very good theory at least. However I've become uncertain of it. Could be that a huge part of it is ok, if only you could train everyone in RAII and constructors/destructors. But then there are close pesky fopen/fclose/malloc/free you have to get rid of. And a lot of complexity around templates, unrelated, but can you allow C++ in a codebase but rigorously ban certain aspects? Maybe draw an analogy to Itanium. Lots of obviously good features, not even all that novel. But must we really combine them all together all at once? (register windows a la SPARC, loop unrolling a la any decent compiler..) And maybe memory is really vastly more interesting than other resources?Oh, and locks, special case those too... Mika your switch example, besides being invalid C++, is just not fair. I don't think people even think to write their code like that. Introducing variables at the top of a switch is rare, esp. initializing them. That C allows variables declared anywhere, and open braces anywhere, seems little known and little taken advantage of. Everyone just moves all the locals to the top, and either programmers do careful static flow analysis, or "lazily" (but reasonably) "over initialize" things, like maybe to 0 or { 0 }. C++ is what really fixes this properly and people know and understand it. Declare stuff anywhere, closest to first, use, and preferably initialized or a user defined type with a constructor. EXCEPT that it doesn't play nicely with goto, and if you aren't using exceptions, then goto is the next best thing...so then you are forced into something closer to the C style, though you gain constructors to help some. And hopefully the compiler can optimize away a lot of the unnecessary initialization... Java and I presume C# have a nice feature here too where they require the compiler to error for use of uninitialized variables, though I suspect the specced algorithm misses some things, like: if (...) initialize x common code if (same thing) use x <== possible use of uninitialize x, not At least I've seen other tools (not Java/C# compilers, I don't use those) get confused by this.. - Jay > To: hendrik at topoi.pooq.com> Date: Tue, 12 Feb 2008 05:41:31 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > hendrik at topoi.pooq.com writes:> >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> >> I don't think this is what Tony meant. In C++, an opening brace> >> starts a block, but every local declaration in that block has its own> >> unique scope that only starts at that declaration and goes to the end> >> of the block. This is particularly messy because the local declarations> >> of a block need not all precede all the statements,> >> >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations.> > switch (a) {> int x=7;> case 0:> use(x); /* oops */> ...> }> > goto somewherefun;> > {> int y=7;> > somewherefun:> use(y); /* oops again */> }> > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such.> > Sounds to me like you're talking about Modula-3's WITH!> > Mika _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 15:05:46 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:05:46 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080212135205.GC22149@topoi.pooq.com> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: Agreed! C++ vs. WITH, C++ wins by not indenting unnecessarily. See that change I was fiddling with in Time.m3 for examle. Hm. Can we get consensus on a language change? :) BEGIN VAR a := 1; IO.PutInt(a); VAR b := 2, (* ? *) c := 3; (* ? *) IO.PutInt(b); ? Easier to require "VAR" on each, a bit wordy. - Jay > Date: Tue, 12 Feb 2008 08:52:05 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote:> > hendrik at topoi.pooq.com writes:> > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> > >> I don't think this is what Tony meant. In C++, an opening brace> > >> starts a block, but every local declaration in that block has its own> > >> unique scope that only starts at that declaration and goes to the end> > >> of the block. This is particularly messy because the local declarations> > >> of a block need not all precede all the statements,> > >> > >That is, in my opinion, one of the few things that C and C++ did right, > > >well, almost right. It permits a coding style in which every > > >variable declaration is initialised, and is declared if and only if it > > > > You can do all kinds of fun stuff with C's declarations/initializations.> > > > switch (a) {> > int x=7;> > case 0:> > use(x); /* oops */> > ...> > }> > > > goto somewherefun;> > > > {> > int y=7;> > > > somewherefun:> > use(y); /* oops again */> > }> > That's more a problem with C's control structures. Each case should be > a block of its own. The bits outside any case shouldn't be there. > etc., etc.> > > > > > > >has a value. Now that's a useful property. It fails for recursion, > > >so there are limits in how far it can apply. And when coding like this, > > >you want the simplest syntax to define a constant identifier -- one > > >whose value cannot be rebound except by reexecuting the entire block. > > >Making something that can change should require more effort -- like > > >adding a keyword "var" or some such.> > > > Sounds to me like you're talking about Modula-3's WITH!> > Close, except for syntax. If you use WITH in the stype I'm > advocating you end up with extremely deep syntactic nesting, and you > indent off the side of the page. Also, the whole WITH syntax is quite > heavy.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 16:57:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 15:57:25 +0000 Subject: [M3devel] utime.i3 and imported data Message-ID: For good reason, imported (dynamically linked) data doesn't work great on Win32. Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];} for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 17:27:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 16:27:38 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: sorry, still not a bad idea, but not where my crash is. I wasn't paying close enough attention. Those aren't used on NT386GNU. The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone); I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:07:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:07:24 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: well..we were accessing fields at the end of struct tm that aren't there..switched from DateBsd to DateLinux and now my exact first proposal stands. :) I worked around but it is lame, imho more lame than my suggestion. My suggestion still imports/shares the data, just via a C function call, so that the right declarations are present. The right declarations are..difficult in Modula-3. You'd have to declare the variables as pointers and change their name, and then somehow either layer portable code over that, or fork DateBsd/DateLinux to DateCygwin..which I just don't think is worth it. I don't like per-platform forks, too much duplicity, too much multiplication out of code, too much code, too much cruft, too little maintenance.... better to merge stuff if it isn't a mess and have less overall source code to maintain.... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] utime.i3 and imported dataDate: Tue, 12 Feb 2008 16:27:38 +0000 sorry, still not a bad idea, but not where my crash is.I wasn't paying close enough attention. Those aren't used on NT386GNU.The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone);I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:21:15 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:21:15 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: I think I just said this over the weekend, but really, I should be able to put in modules and not be forced to put them in an interface. Look at the cygwin Utime.i3/m3/C.c for example... Yeah, it's a workaround, that I'd like to remove, but it could easily represent a non-workaround.. There's no real "interface/module" here, it's just that I wrote some of the code in C. sorry to be such an annoying whiner..but I ran into this multiple times over a short span of time... - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:26:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:26:24 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: Jay, Modula-3 has a perfectly good way of saying what you want as PACKED types. Whether they are fully implemented or not is another question. -- Tony On Feb 12, 2008, at 6:34 AM, Jay wrote: > I strongly suggest that at least in some contexts, no padding ever > be quietly inserted, and that all seeming need for padding generate > an error, unless explicitly quashed, preferably by explicit > insertion of padding fields by the programmer, and/or rearrangement > sorted by size, or possibly some annotation of the overall struct/ > record/class/module, an annotation such as <* silent padding ok*>. > Alignment issues really bug me... > I realize many data structures are only ever seen in memory, by one > process, so it doesn't matter, but when it matter, the languages/ > tools seem to fall down. > As well, "padding" fields should be annotated as such and the > compiler warn or error if they aren't needed. > > It's just dumb that code like: > > struct > { > int32 a; > int64 b; > }; > > when defining some stable important binary layout can have a > varying but silently allowed meaning based on command line switches > or targets.. Yes, I'm a dumb programmer to write it, but man the > tools are lagging. > > This will fall on deaf ears and far from sufficient ears even if > they were hearing. > It's the C compilers that are somewhat broken here imho. > C is unnecessarily broken here. Imho it's a big cause for headaches > and easily solved....it doesn't have to stink so badly, if anyone > cared.. > > I have had to maintain structs that had to look the same across > different targets and therefore insert target-dependent padding. > Ok, but it should have been easier. When I was done, I put in > compile time asserts as to the offset of every single field so the > next guy would have an easier time, and assiduously commented every > byte of padding in the struct and its target-dependentness.... > This was like for shared memory. > > Grumble, > - Jay > > > > > From: darko at darko.org > > To: rodney.bates at wichita.edu > > Date: Tue, 12 Feb 2008 15:37:52 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] <*LAZYALIGN*> > > > > That's not quite right. Certain Mac API structures need to be > aligned > > to Motorola 68K alignment for historical reasons. All other > structures > > should use normal alignment to be compatible with C and Unix > > interfaces. The alignment change was implemented to be supported > only > > in packed structures as a natural and intuitive way to "force" > > alignment. You could view it as a bug fix to overly restrictive > > alignment rules in packed structures. > > > > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > > > > > It sounds like all that Mac OS X needs is for _all_ types in an > entire > > > program to use the liberal packing rules. Have I understood > > > correctly? > > > I would have no grief over that. > > > > > > Darko wrote: > > >> The liberalised alignment rules are required for the native > Mac OS > > >> X API and should stay. You cannot use that API without them. I > > >> think the pragma is not required and can be removed. I agree with > > >> all the points you make. The effect of the modified alignment > > >> rules it to allow *packed* structures to have members aligned on > > >> byte boundaries. This has the effect of packing the fields in the > > >> tightest arrangement allowed by the platform. This might affect > > >> performance, but if the user is concerned about this they should > > >> specify field bit sizes that deliver improved performance. I > don't > > >> see a need to specify this on a structure level, for the reasons > > >> you give and because the difference isn't significant enough in > > >> the case of packed structures and their physical layout and > > >> restrictions are platform dependent anyway. > > >> I might also add that the alignment code is currently broken on > > >> I386_DARWIN. > > >> - Darko > > >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > > >>> Does anybody know about the status of pragma <*LAZYALIGN*>? > Is it > > >>> being used anywhere? > > >>> > > >>> It is not documented in pragmas.html. The compiler front end > > >>> appears > > >>> to accept it. (In fact, Decls.m3 contains constants that suggest > > >>> limitations on what declarations the pragma can appear on, > but these > > >>> are not actually enforced.) It liberalizes the alignment rules, > > >>> generally allowing scalars to start on any byte boundary. > > >>> > > >>> Pickles have to be able to reconstruct the layout of types as > the > > >>> compiler would have done it for a machine (on which a now- > being-read > > >>> pickle was written) with different word size and alignment > > >>> properties. > > >>> Currently, pickles are completely unaware of lazy alignment. It > > >>> would have to be encoded in type descriptions generated by the > > >>> compiler > > >>> using TipeDesc and read by pickles using RTTipe. > > >>> > > >>> Most troubling to me is what looks like a linguistic > Pandora's box. > > >>> The pragma can be associated with any constant, variable, or > type > > >>> _declaration_ (not type definition), with the result that > different > > >>> values of the same type can actually be different in their > alignment > > >>> rules and thus their layout. Similarly for different identifiers > > >>> equated to the same type. Although the effects of this could > > >>> possibly > > >>> be hidden from the programmer in purely safe code, not so with > > >>> unsafe > > >>> code. I haven't thoroughly thought this through, but seems to me > > >>> to > > >>> really fly in the face of the whole typing philosophy of the > > >>> language. > > >>> > > >>> For example, if pickles were to read in an object value, and > there > > >>> were >1 variants of the object's type in the reading program, > > >>> differing > > >>> only in the alignment rules, how would it decide which one to > build? > > >>> In fact, ignoring pickles altogether and just looking at a > single > > >>> program, > > >>> if the object's type doesn't actually uniquely give its memory > > >>> layout, > > >>> how can it be accessed correctly? > > >>> > > >>> Additionally, a quick look at the compiler suggests it won't > > >>> generate > > >>> correct code for whole record assignment when the LHS and RHS > are > > >>> the > > >>> same type but have different alignment characteristics. > > >>> > > >>> The more I think about it, it seems the only workable > > >>> possibilities are: > > >>> > > >>> 1) Require the pragma to be associated only with a type > > >>> _definition_ not a > > >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > > >>> this a > > >>> property of the type that propagates to all names for the > type and > > >>> all variables, constants, etc. Also, this would make this > property > > >>> a part of the type signature that pickles uses when reading, - > OR- > > >>> > > >>> 2) Forget it altogether. > > >>> > > >>> What do people think? > > >>> -- > > >>> ------------------------------------------------------------- > > >>> 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 > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Tue Feb 12 18:33:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:33:01 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: This was to "fix" building NT386GNU because lseek was returning int or long instead of off_t. My mistake by changing the wrong side of things. The return type is fixed and NT386GNU is ok with the "VAL". - Jay From: jayk123 at hotmail.comTo: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.comSubject: val?Date: Tue, 12 Feb 2008 06:22:28 +0000 Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available.There is/was a compilation problem with what I was doing.I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:34:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:34:12 -0500 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: <8B40FF77-0AF5-4907-9935-03CEE1E24BB7@cs.purdue.edu> Thanks Jay and Olaf for your explanations. I am only ever a general user of the scripts, but perhaps as a maintainer I should understand them better. On Feb 12, 2008, at 5:34 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I notice scripts/PKGS is no longer in the repository. Does this get >> generated somehow now? I know that do-cm3-std.sh depends on it >> because >> my copy of PKGS was broken (missing sysutils). Can someone >> explain to >> me how the build scripts have changed and how I should be using them? > > PKGS has never been checked-in and should not as far as I know. > It contains workspace-dependent paths and is built by find-packages.sh > if I remember correctly. All shell scripts will generate it if it > does not exist. It can be deleted any time, and indeed must be deleted > if packages are added (or they will not be found). This is arguably > a bug, > but then all the scripts were never intended to be a general user > interface > for CM3 users (only for the maintenance). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 12 18:42:01 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:01 -0500 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Aren't these all superseded by gettimeofday? I say just not support the global variable access. Utime.i3 on other platforms does not have these globals. On Feb 12, 2008, at 12:07 PM, Jay wrote: > well..we were accessing fields at the end of struct tm that aren't > there..switched from DateBsd to DateLinux and now my exact first > proposal stands. :) > > I worked around but it is lame, imho more lame than my suggestion. > My suggestion still imports/shares the data, just via a C function > call, so that the right declarations are present. > The right declarations are..difficult in Modula-3. > You'd have to declare the variables as pointers and change their > name, and then somehow either layer portable code over that, or > fork DateBsd/DateLinux to DateCygwin..which I just don't think is > worth it. I don't like per-platform forks, too much duplicity, too > much multiplication out of code, too much code, too much cruft, too > little maintenance.... better to merge stuff if it isn't a mess and > have less overall source code to maintain.... > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] utime.i3 and imported data > Date: Tue, 12 Feb 2008 16:27:38 +0000 > > sorry, still not a bad idea, but not where my crash is. > I wasn't paying close enough attention. Those aren't used on NT386GNU. > The crash is probably here: > > C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): > date.zone := M3toC.CopyStoT (tm.tm_zone); > > I don't know why yet. (meta reason -- these time formats aren't > worthwhile even if forward slashes in paths and X Windows are....) > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Tue, 12 Feb 2008 15:57:25 +0000 > Subject: [M3devel] utime.i3 and imported data > > For good reason, imported (dynamically linked) data doesn't work > great on Win32. > Functions work much better. Data can work, but you generally need > the header to say __declspec(dllimport), to change it to a > declaration of a pointer. I've seen GNU ld has some workaround but > I'm not familiar with it, it doesn't worthwhile to me, and I'm > having a problem. > > I strongly suggest all the Utime.i3: > > <*EXTERNAL*> VAR timezone: time_t; > <*EXTERNAL*> VAR daylight: int; > <*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; > > be changed to functions: > > <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t; > <*EXTERNAL Utime__get_daylight*> get_daylight(): int; > <*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; > > > with an implementation in C: > > UtimeC.c > #include > time_t Utime__get_timezone(void) > { > return timezone; > } > > int Utime__get_daylight(void) > { > return daylight; > } > > char* Utime__get_tzname(unsigned a) > { > return tzname[a]; > } > > for now I'm going to try another workaround..where NT386GNU has > this data as not external and some C code to call tzset and then > copy the data from the C globals to Modula-3 globals. > > The datetime feature I added to Quake is crashing, I think due to > this... > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:42:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:57 -0500 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: The globals are gross, and not available on other platforms. Let's just drop them... On Feb 12, 2008, at 12:21 PM, Jay wrote: > I think I just said this over the weekend, but really, I should be > able to put in modules and not be forced to put them in an > interface. > Look at the cygwin Utime.i3/m3/C.c for example... > Yeah, it's a workaround, that I'd like to remove, but it could > easily represent a non-workaround.. > There's no real "interface/module" here, it's just that I wrote > some of the code in C. > > sorry to be such an annoying whiner..but I ran into this multiple > times over a short span of time... > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:43:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:43:53 -0500 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: The log tells the story much better than random comments in the code. On Feb 12, 2008, at 1:18 AM, Jay wrote: > I added some files a while ago and someone either complained or > added them, so I've been adding them since. > > - Jay > > > > Date: Tue, 12 Feb 2008 05:20:47 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 08/02/12 05:20:47 > > > > Modified files: > > cm3/m3-sys/cm3/src/: m3makefile > > > > Log message: > > Let's avoid RCS id stuff shall we. Just clutters up the files... > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Tue Feb 12 18:50:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:50:03 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: <98447784-CE9A-40E4-8305-DA711A0EEBE1@cs.purdue.edu> Hear hear! On Feb 12, 2008, at 7:56 AM, Mika Nystrom wrote: > > Can you just generate the Modula-3 code you want using a Python > script or COBOL or whatever you like instead of trying to foist > preprocessing nastiness on innocent users of high-level Modula-3? > > Preprocessing is super nasty. It's not just a question of human > readability. m3tk has to be able to read the code, too. I should > be able to write a program that reads in (using m3tk) an arbitrary > Modula-3 interface and understands it to the point that it can > generate Network Object stubs, inter-language call stubs, etc. The > stubs should ALSO be human- and m3tk-readable after the > transformation! > This should work even if the programmer has been very "clever" in > his use of Modula-3 constructs. (Just try getting something like > that to work with C or C++... it's hopeless once the preprocessor > gets involved, and possibly before.) > > Also if I may make a little request, if at all possible, please try > not to break binary compatibility with gcc-compiled C and Fortran > on NT386GNU (not sure if your ideas about calling conventions could > possibly do that...) > > Mika > > Jay writes: >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> I insist that it depends. >> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code. >> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility. >> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct. >> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision. >> It goes both ways. >> =20 >> Yes, you could endeavor factor things down so that everything >> common is in = >> common, and everything not-common is in platform-specific. But >> this is inad= >> equate I think. The tail is wagging the dog unnecessarily I think. >> If my co= >> de very nearly all goes together, don't make me separate it. Also >> sometimes= >> a different factoring is "encouraged" for other reasons, to match >> someone = >> else's factoring. Look at the C*.i3 files. They actually can be >> almost all = >> be nearly the same, yet they are hardly shared at all. I realize >> you could = >> also do a sort of "forwarding", though I'm not sure that Modula-3 >> offers al= >> l the right capabilities for this. Type forwarding, sure. But how >> about pro= >> cedure forwarding? Like nt386\cstdio.i3 fopen =3D common >> \ccommonstdio.i3 fo= >> pen? And having to duplicate a line per type/procedure is lame >> anyway, you = >> KIND OF want "module inheritance". However, if you allow >> preprocessing base= >> d on target, perhaps the need for that goes away. >> =20 >> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno. >> =20 >> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source. >> But it is only heuristic. >> =20 >> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file. >> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable. >> =20 >> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like: >> <*EXTERN FOOAPI WINAPI*> fopen(); >> FOOAPI for OS/FOO, WINAPI ignored. >> WINAPI for NT386, FOOAPI ignored. >> The One True Calling Convention for all others, calling convention >> ignored. >> =20 >> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future. >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system. >> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant. >> That could be also. >> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) ) >> =20 >> =20 >> - Jay >> >> >> >>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: >>> hosking at cs.purdue.e= >> du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, >> 11 Feb 20= >> 08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, >> 2008, at 8:= >> 37 PM, Darko wrote:> > > I think it's not a good idea. I think all >> platform= >> specific code > > should be in a separate file. I'd also like to >> see an op= >> tion to > > move calling conventions to the makefile rather than >> in pramas = >> to > > avoid having to duplicate interface files just to have a >> different >= >>> calling convention for a different platform.> >> > - Darko> >> >> >>> > On 1= >> 2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought >> this throug= >> h.> >>> >> I wonder if "preprocessing" dependent only on "target" >> is a good= >>>>> idea.> >>> >> Something like either the ability to prefix >>>>> pragmas wit= >> h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> >> Somethi= >> ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> >>> >>> >= >>> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can >>> of worm= >> s.> >> Where can they be placed? Only at "global" scope? (ie: >> toplevel in >= >>>> an interface/module).> >>> >> What about IF_OSTYPE?> >> What >>>> about expr= >> essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS >> (NT)> >>> >= >>> etc.> >>> >> I don't really have enough interest here to work >>> through thi= >> s, > >> just sending out the bait...> >>> >> Obviously this was >> triggered b= >> y my happening into the odbc > >> directory and bringing up >> ignoring WINAPI= >> on non-NT386 or > >> prefixing calling conventions with a target.> >> >>> >> = >> This reminds me of an important point here however -- nobody else >> > >> is g= >> oing to make the mistake of ever having multiple calling > >> >> conventions. = >> Therefore the generality of prefixing WINAPI with > >> NT386: is >> useless.> = >>>> Unless Mac68K support is added.> >>> >> And here is some >>>> rationale even.= >> The PC and Mac evolved from > >> "small" systems, where assembly >> programmi= >> ng was common, more > >> people knew more lower level details and >> playing g= >> ames with > >> calling conventions was something anyone could do. >> Most othe= >> r > >> current systems are rooted in C programming. Working in C, >> calling >= >>>> conventions are generally in a hidden layer below what anyone > >>>> >> thin= >> ks about. Therefore, the smaller number of capable people > >> >> working at t= >> hat level have the good sense to only have one calling > >> >> convention. No = >> more systems will evolve from "small", at least not > >> without >> having obs= >> erved this history. Therefore, there will no > >> longer be >> multiple callin= >> g conventions.> >>> >> That is my theory at least.> >>> >> Oh, >> Windows does= >> also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >> _________________________________________________________________ >> Climb to the top of the charts!=A0Play the word scramble challenge >> with sta= >> r power. >> http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlink_ja= >> n= >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> I insist that it depends.
>> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code.
>> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility.
>> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct.
>> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision.
>> It goes both ways.
>>  
>> Yes, you could endeavor factor things down so that everything >> common i= >> s in common, and everything not-common is in platform-specific. >> But this is= >> inadequate I think. The tail is wagging the dog unnecessarily I >> think. If = >> my code very nearly all goes together, don't make me separate >> it. = >> ;Also sometimes a different factoring is "encouraged" for other >> reasons, to= >> match someone else's factoring. Look at the C*.i3 files. They >> actually can= >> be almost all be nearly the same, yet they are hardly shared at >> all. I rea= >> lize you could also do a sort of "forwarding", though I'm not sure >> that Mod= >> ula-3 offers all the right capabilities for this. Type forwarding, >> sure. Bu= >> t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D >> common\cco= >> mmonstdio.i3 fopen? And having to duplicate a line per type/ >> procedure is la= >> me anyway, you KIND OF want "module inheritance". However, if you >> allow pre= >> processing based on target, perhaps the need for that goes away.
>>  
>> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno.
>>  
>> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source.
>> But it is only heuristic.
>>  
>> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file.
>> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable.
>>  
>> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like:
>> <*EXTERN FOOAPI WINAPI*> fopen();
>> FOOAPI for OS/FOO, WINAPI ignored.
>> WINAPI for NT386, FOOAPI ignored.
>> The One True Calling Convention for all others, calling convention >> ignored.= >>
>>  
>> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future.>> >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system.
>> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant.
>> That could be also.
>> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) )
>>  
>>  
>>  - Jay

>> >>
>>
>> > CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: >> hosking at c= >> s.purdue.edu
> Subject: Re: [M3devel] "target specific >> pragmas"?
&= >> gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: >> darko at darko.org
&g= >> t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, >> Darko wro= >> te:
>
> > I think it's not a good idea. I think >> all platfor= >> m specific code
> > should be in a separate file. I'd >> also like t= >> o see an option to
> > move calling conventions to the >> makefile r= >> ather than in pramas to
> > avoid having to duplicate >> interface f= >> iles just to have a different
> > calling convention for >> a differ= >> ent platform.
> >
> > - Darko
> >> >
> >> R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >> >
> >= >> ;> So I have NOT thought this through.
> >>
> >> >>= >> I wonder if "preprocessing" dependent only on "target" is a good >>
> = >> >> idea.
> >>
> >> Something like >> either the = >> ability to prefix pragmas with a target,
> >> or an >> "iftarget"= >> and "ifnottarget" pragma.
> >>
> >> >> Something like= >> so:
> >>
> >> <* IF_TARGET NT386 >> *>
> = >> >> <* END_IF_TARGET*>
> >>
> >> >>
>= >> >> <* IF_TARGET NT386 *>
> >> <* >> END_IF_TARGET*= >> >
> >> It's a small can of worms.
> >> >> Where can= >> they be placed? Only at "global" scope? (ie: toplevel in
> >> >>= >> an interface/module).
> >>
> >> What about >> IF_OSTY= >> PE?
> >> What about expressions?
> >> >> IF_TARGET NT3= >> 86 OR NTAMD64
> >>
> >> IF_TARGET STARTS >> (NT)
>= >> ; >>
> >> etc.
> >>
> >> >> I don't = >> really have enough interest here to work through this,
> >> >> ju= >> st sending out the bait...
> >>
> >> >> Obviously this= >> was triggered by my happening into the odbc
> >> >> directory an= >> d bringing up ignoring WINAPI on non-NT386 or
> >> >> prefixing c= >> alling conventions with a target.
> >>
> >> >> This re= >> minds me of an important point here however -- nobody else >>
> >>= >> ; is going to make the mistake of ever having multiple calling >>
> >= >> ;> conventions. Therefore the generality of prefixing WINAPI >> with
&g= >> t; >> NT386: is useless.
> >> Unless Mac68K >> support is ad= >> ded.
> >>
> >> And here is some rationale >> even. The= >> PC and Mac evolved from
> >> "small" systems, where >> assembly = >> programming was common, more
> >> people knew more >> lower level= >> details and playing games with
> >> calling >> conventions was s= >> omething anyone could do. Most other
> >> current >> systems are = >> rooted in C programming. Working in C, calling
> >> >> convention= >> s are generally in a hidden layer below what anyone
> >> >> think= >> s about. Therefore, the smaller number of capable people
> >> >> = >> working at that level have the good sense to only have one calling >>
>= >> >> convention. No more systems will evolve from "small", at >> least no= >> t
> >> without having observed this history. >> Therefore, there = >> will no
> >> longer be multiple calling >> conventions.
> &= >> gt;>
> >> That is my theory at least.
> >> >>
&g= >> t; >> Oh, Windows does also have __thiscall and __clrcall. >> __thiscall= >> is
> >> only x86
>


Climb to >> the top= >> of the charts!=A0Play the word scramble challenge with star power. >> > =3D'http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlin= >> k_jan' target=3D'_new'>Play now! >> = >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_-- From hosking at cs.purdue.edu Tue Feb 12 18:54:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:54:15 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212130518.F0C7B10D4659@birch.elegosoft.com> References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: Jay, I *really* dislike the idea that you are putting target-specific code in a subdirectory labeled Common! If I want to search for target-specific stuff I grep for directories labeled by that target. Please, please, please think about the global picture before making these sorts of local changes! Please back this change out and put this where it belongs in cm3/m3- libs/m3core/src/C/NT386. I am happy to do it for you but I have other things to do with my time! On Feb 12, 2008, at 2:05 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 14:05:18 > > Modified files: > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c > > Log message: > fix (NT386 only) From hosking at cs.purdue.edu Tue Feb 12 19:00:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 13:00:39 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212125650.7DE8D10D4659@birch.elegosoft.com> References: <20080212125650.7DE8D10D4659@birch.elegosoft.com> Message-ID: <3BDD1B0E-CD23-43D1-9BC0-7B36FE6024AF@cs.purdue.edu> The C stuff is not intended to expose a full C API to Modula-3 programmers. It is there mostly for bridging to C-based libraries, particularly platform-specific functionality for platforms that are implemented in C. Some of that bridging is done in the OS-specific unix subdirectories and some in the C subdirectories. Choosing where to put that bridge code is a matter of style I guess, but it should probably be a matter of consensus among the developers of CM3. So, do folks out there have any opinions on how to best structure these bridging portions of m3core? I would argue for the minimum needed to support core M3 functionality. Jay seems to want to throw everything including the kitchen sink into the core libraries. I would argue that doing so makes the job of maintaining and porting Modula-3 a little more onerous. On Feb 12, 2008, at 1:56 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 13:56:50 > > Added files: > cm3/m3-libs/m3core/src/unix/NT386/: Unix.i3 Uuio.i3 > > Log message: > a fair amount of "unix i/o" is directly provided by msvcr*.dll and > should perhaps be exposed /somewhere/. Here is a start, of sorts. From dragisha at m3w.org Tue Feb 12 18:58:44 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 18:58:44 +0100 Subject: [M3devel] wtf "code generation errors"? Message-ID: <1202839124.623.1.camel@faramir.m3w.org> % cm3 --- building in ../LINUXLIBC6 --- new source -> compiling Connection.i3 new source -> compiling Connection.m3 new source -> compiling PDU.i3 new source -> compiling PDU.m3 "../src/PDU.m3", line 107: warning: not used (len) "../src/PDU.m3", line 104: warning: not used (b) "../src/PDU.m3", line 116: warning: open array passed by value (o) "../src/PDU.m3", line 118: warning: not used (cStr) "../src/PDU.m3", line 116: warning: not used (b) "../src/PDU.m3", line 116: warning: not used (o) "../src/PDU.m3", line 160: warning: not used (c) "../src/PDU.m3", line 59: warning: not used (GetInt) 8 warnings encountered new source -> compiling SMPP.m3 "../src/SMPP.m3", line 1: 4 code generation errors 1 error encountered compilation failed => not building program "smpp" Fatal Error: package build failed -- Dragi?a Duri? From hendrik at topoi.pooq.com Tue Feb 12 20:13:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 14:13:38 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: <20080212191338.GA24578@topoi.pooq.com> On Tue, Feb 12, 2008 at 02:05:46PM +0000, Jay wrote: > Agreed! > C++ vs. WITH, C++ wins by not indenting unnecessarily. > See that change I was fiddling with in Time.m3 for examle. > > Hm. Can we get consensus on a language change? :) > > BEGIN VAR a := 1; > IO.PutInt(a); > VAR b := 2, (* ? *) > c := 3; (* ? *) > IO.PutInt(b); > > ? Easier to require "VAR" on each, a bit wordy. > > - Jay That would work. But I'd use CONST more than VAR (if I had a choice) And I'd like to be able to specify the type. I'm a fanatic about making types explicit. -- hendrik From hosking at cs.purdue.edu Tue Feb 12 21:05:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 15:05:43 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202839124.623.1.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: Did something change in m3middle/m3front lately? On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > % cm3 > --- building in ../LINUXLIBC6 --- > > new source -> compiling Connection.i3 > new source -> compiling Connection.m3 > new source -> compiling PDU.i3 > new source -> compiling PDU.m3 > "../src/PDU.m3", line 107: warning: not used (len) > "../src/PDU.m3", line 104: warning: not used (b) > "../src/PDU.m3", line 116: warning: open array passed by value (o) > "../src/PDU.m3", line 118: warning: not used (cStr) > "../src/PDU.m3", line 116: warning: not used (b) > "../src/PDU.m3", line 116: warning: not used (o) > "../src/PDU.m3", line 160: warning: not used (c) > "../src/PDU.m3", line 59: warning: not used (GetInt) > 8 warnings encountered > new source -> compiling SMPP.m3 > "../src/SMPP.m3", line 1: 4 code generation errors > 1 error encountered > compilation failed => not building program "smpp" > Fatal Error: package build failed > > -- > Dragi?a Duri? From rcoleburn at scires.com Tue Feb 12 21:16:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 12 Feb 2008 15:16:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <47B1B848.1E75.00D7.1@scires.com> Jay: My understanding of Modula-3 is that rather than cluttering up the source code with a bunch of preprocessor directives to deal with the various changes needed by various platforms, a separate source file is used for platforms whose implementation must diverge. The m3makefile is used to control the selection of these platform sources at build time. I like this approach much better. Regards, Randy >>> Jay 2/11/2008 8:21 PM >>> So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 12 22:12:45 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:12:45 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 13:50:22 GMT." Message-ID: <200802122112.m1CLCjU0006778@camembert.async.caltech.edu> Your seeksomething = Ctargetstdio.seeksomething should work. Another thing that might work well is to use generics. For instance, have some interfaces Win32Types.i3 MacOSTypes.i3 FreeBSDTypes.i3 And then build your other stuff as generics passing in OSTypes... of course you can't do *everything* with generics, but type variants you can do. About preprocessing. It's clear you're going to have variable code. When you deal with OS things, of course you will. Currently this variability is expressed in Quake. There's no way of getting away from a certain amount of variability as long as you're interfacing with an OS, I think we all know that. But there's a difference between doing it in Quake and in Modula-3, which is why I used the expression "foisting preprocessing on innocent users of high-level Modula-3". As long as you do it in Quake, no one will expect things like m3tk to work properly all the time. Once you do it in Modula-3 itself, however, you're inviting users to code absolutely normal modules with preprocessing that really have no need for preprocessing. You can't really say "here's a part of the language we're using that you probably shouldn't use." If it's there, you have to expect programmers to use it. If it's not, if they do weird things in Quake, or generate code in Python, on the other hand, they themselves had better know what they are doing. Mika Jay writes: >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Mika good point, I know that, forgot, thanks for reminding me. > One of the interesting things about Modula-3, or rather anything but C an= >d C++, is easy parsing, easy building of other tools. >=20 >Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the pkg tree? = >You know, they can't understand the source tree without understanding m3mak= >efiles. >=20 >I started a little experiment here. >I added m3-libs/m3core/src/C/common/Cstdio.i3. >This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386. >I'm thinking either: > a) I'm not quite on base and just fork it per-target, as it was > b) provide a little bit of C code with #ifdefs, like making the SEEK_* c= >onstants into VARs and using C to initialize them. That's a bit of a downer= > though, since constants ought to be constants. > c) factor it somehow as I was alluding, like, well, again I'm not sure M= >odula-3 has what I'd want here, but at least for types and constants, you c= >an push the non-portable stuff into Ctargetstdio.i3 and then expose them in= > Cstdio.i3, forking only Ctargetstdio.i. >=20 >I'll explain so I can get my question in. :) >=20 >I understand, say: >=20 >Ctargetstdio.i3 (* one of these per target, with not much content *)=20 >CONST > SEEK_CUR =3D ..; (* target specific probably *)=20 > SEEK_SET =3D ..; ditto=20 > SEEK_END =3D ..; ditto =20 >TYPE > FOO =3D ... ditto =20 >=20 >Cstdio.i3 (* portable *)=20 > CONST > SEEK_CUR =3D Ctargetstdio.SEEK_CUR; > SEEK_SET =3D Ctargetstdio.SEEK_SET; > SEEK_END =3D Ctargetstdio.SEEK_END; >TYPE > FOO =3D Ctargetstdio.FOO; >=20 >FILE =3D UNTRACED REF RECORD END; >=20 > procedure fopen(a: const_char_star; b: const_char_star): FILE; >=20 >It is tedious but I believe it works. >It'd be nice, I think, if every symbol in one interface could be automatica= >lly aliases/exposed in another. > At least for this purpose, maybe not for any other. I'm speculating here,= > so please respond kindly. :) >The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place. >=20 >However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another. >Nevermind for now how you can portably call it. >=20 >Ctargetstdio.i3 (* one of these for every target, but another question in a= > sec ... *) >=20 > PROCEDURE seeksomething(a: off_t); let's say it is int on some pl= >atforms. >=20 >Cstdio.i3 (* the portable one *) >=20 >seeksomething =3D Ctargetstdio.seeksomething; does this work? I should t= >ry it out, read the docs. >=20 >But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int. >It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants. >You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE). >OS_TYPE implies less work, nice. >=20 >Perhaps concatening stuff in arbitrary way with Quake really is the way? >It seems almost sarcastic, but perhaps not. >=20 >As long as the pkg store is easily parsed? >(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..) >=20 >But for that matter --- could be processed by the compiler and = >result in a file with it already accounted for and ship that. Isn't that ju= >st as good? EXCEPT that more thought would have to go into the spec, wherea= >s m3makefile is already a general purpose system that anyone can do anythin= >g with? >=20 >?? >=20 > - Jay > > > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From:= > mika at async.caltech.edu> > > Can you just generate the Modula-3 code you wa= >nt using a Python> script or COBOL or whatever you like instead of trying t= >o foist> preprocessing nastiness on innocent users of high-level Modula-3?>= > > Preprocessing is super nasty. It's not just a question of human> readabi= >lity. m3tk has to be able to read the code, too. I should> be able to write= > a program that reads in (using m3tk) an arbitrary> Modula-3 interface and = >understands it to the point that it can> generate Network Object stubs, int= >er-language call stubs, etc. The> stubs should ALSO be human- and m3tk-read= >able after the transformation!> This should work even if the programmer has= > been very "clever" in> his use of Modula-3 constructs. (Just try getting s= >omething like> that to work with C or C++... it's hopeless once the preproc= >essor> gets involved, and possibly before.)> > Also if I may make a little = >request, if at all possible, please try> not to break binary compatibility = >with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about = >calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--= >_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset= >=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist= > that it depends.> >Putting every platform-specific piece of code in its ow= >n file/directory can=3D> > lead to mass duplication of nearly identical cod= >e.> >Sometimes an #if here or there goes very far in /improving/ code maint= >ainab=3D> >ility.> >A lot of #if here there and everywhere of course can ha= >ve the opposite effe=3D> >ct.> >And I realize if you were to drop support f= >or a target, it is easier to fin=3D> >d/delete files/directories than #ifs,= > but I don't think that's a good enoug=3D> >h reason to sway the decision.>= > >It goes both ways.> >=3D20> >Yes, you could endeavor factor things down s= >o that everything common is in =3D> >common, and everything not-common is i= >n platform-specific. But this is inad=3D> >equate I think. The tail is wagg= >ing the dog unnecessarily I think. If my co=3D> >de very nearly all goes to= >gether, don't make me separate it. Also sometimes=3D> > a different factori= >ng is "encouraged" for other reasons, to match someone =3D> >else's factori= >ng. Look at the C*.i3 files. They actually can be almost all =3D> >be nearl= >y the same, yet they are hardly shared at all. I realize you could =3D> >al= >so do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >=3D> >l the right capabilities for this. Type forwarding, sure. But how abo= >ut pro=3D> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D3D common\ccom= >monstdio.i3 fo=3D> >pen? And having to duplicate a line per type/procedure = >is lame anyway, you =3D> >KIND OF want "module inheritance". However, if yo= >u allow preprocessing base=3D> >d on target, perhaps the need for that goes= > away.> >=3D20> >While extern C varargs functions are generally useless in = >Modula-3, and the=3D> >refore extern __cdecl is fairly rare, it DOES occur = >when you write little h=3D> >elpers in C, such as for errno.> >=3D20> >A go= >od /heuristic/ might be to change the default in any directory that has=3D>= > > no c_source.> >But it is only heuristic.> >=3D20> >Whatever is done here= >, some allowance should probably be made for multiple =3D> >calling convent= >ions in the same file.> >Switching the default to the overwhelming majority= > and then annotating the =3D> >minority is reasonable.> >=3D20> >I still be= >lieve that silently ignoring calling conventions on all but NT386=3D> > is = >VERY reasonable, and that no other platform from here on out will ever =3D>= > >have calling conventions. Esp. not with the same names. When OS/FOO has t= >he=3D> > FOOAPI calling convention, you can just ignore that one on all but= > target =3D> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD p= >ossibly get ug=3D> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();>= > >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >= >The One True Calling Convention for all others, calling convention ignored.= >> >=3D20> >I really believe this is highly highly unlikely to occur, and it= > is not a t=3D> >errible outcome, and this bridge could be crossed in the f= >ar off future.> >The functions that are usually in need of calling conventi= >ons are usually o=3D> >nly present on one system.> >Perhaps ODBC is an extr= >emely rare anomaly and the whole issue is nearly non=3D> >existant.> >That = >could be also.> >A change just for ODBC is probably not the best, though it= > is a very small =3D> >safe harmless change (I always say that :) )> >=3D20= >> >=3D20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.c= >om> From: hosking at cs.purdue.e=3D> >du> Subject: Re: [M3devel] "target speci= >fic pragmas"?> Date: Mon, 11 Feb 20=3D> >08 21:08:46 -0500> To: darko at darko= >.org> > Indeed!> > On Feb 11, 2008, at 8:=3D> >37 PM, Darko wrote:> > > I t= >hink it's not a good idea. I think all platform=3D> > specific code > > sho= >uld be in a separate file. I'd also like to see an op=3D> >tion to > > move= > calling conventions to the makefile rather than in pramas =3D> >to > > avo= >id having to duplicate interface files just to have a different >=3D> > > c= >alling convention for a different platform.> >> > - Darko> >> >> > On 1=3D>= > >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this thro= >ug=3D> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" i= >s a good=3D> > > >> idea.> >>> >> Something like either the ability to pref= >ix pragmas wit=3D> >h a target, > >> or an "iftarget" and "ifnottarget" pra= >gma.> >>> >> Somethi=3D> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* = >END_IF_TARGET*>> >>> >>> >=3D> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGE= >T*>> >> It's a small can of worm=3D> >s.> >> Where can they be placed? Only= > at "global" scope? (ie: toplevel in >=3D> > >> an interface/module).> >>> = >>> What about IF_OSTYPE?> >> What about expr=3D> >essions?> >> IF_TARGET NT= >386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=3D> >> etc.> >>> >> I do= >n't really have enough interest here to work through thi=3D> >s, > >> just = >sending out the bait...> >>> >> Obviously this was triggered b=3D> >y my ha= >ppening into the odbc > >> directory and bringing up ignoring WINAPI=3D> > = >on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >=3D> >This reminds me of an important point here however -- nobody else > >= >> is g=3D> >oing to make the mistake of ever having multiple calling > >> c= >onventions. =3D> >Therefore the generality of prefixing WINAPI with > >> NT= >386: is useless.> =3D> >>> Unless Mac68K support is added.> >>> >> And here= > is some rationale even.=3D> > The PC and Mac evolved from > >> "small" sys= >tems, where assembly programmi=3D> >ng was common, more > >> people knew mo= >re lower level details and playing g=3D> >ames with > >> calling convention= >s was something anyone could do. Most othe=3D> >r > >> current systems are = >rooted in C programming. Working in C, calling >=3D> > >> conventions are g= >enerally in a hidden layer below what anyone > >> thin=3D> >ks about. There= >fore, the smaller number of capable people > >> working at t=3D> >hat level= > have the good sense to only have one calling > >> convention. No =3D> >mor= >e systems will evolve from "small", at least not > >> without having obs=3D= >> >erved this history. Therefore, there will no > >> longer be multiple cal= >lin=3D> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Win= >dows does=3D> > also have __thiscall and __clrcall. __thiscall is > >> only= > x86>=3D20> >______________________________________________________________= >___> >Climb to the top of the charts!=3DA0Play the word scramble challenge = >with sta=3D> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3D3Dst= >arshuffle_wlmailtextlink_ja=3D> >n=3D> >> >--_8b04f633-e2a4-411d-940a-739ab= >79b0616_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Content-Transf= >er-Encoding: quoted-printable> >> >> >> >> >> >e'>I insist that it depends.
> >Putting every platform-specific piece of= > code in its own file/directory can=3D> > lead to mass duplication of nearl= >y identical code.
> >Sometimes an #if here or there goes very far in /im= >proving/ code maintainab=3D> >ility.
> >A lot of #if here there and ever= >ywhere of course can have the opposite effe=3D> >ct.
> >And I realize if= > you were to drop support for a target, it is easier to fin=3D> >d/delete f= >iles/directories than #ifs, but I don't think that's a good enoug=3D> >h re= >ason to sway the decision.
> >It goes both ways.
> > 
> >Yes,= > you could endeavor factor things down so that everything common i=3D>= > >s in common, and everything not-common is in platform-specific. But this = >is=3D> > inadequate I think. The tail is wagging the dog unnecessarily I th= >ink. If =3D> >my code very nearly all goes together, don't make me sep= >arate it. =3D> >;Also sometimes a different factoring is "encouraged" f= >or other reasons, to=3D> > match someone else's factoring. Look at the C*.i= >3 files. They actually can=3D> > be almost all be nearly the same, yet they= > are hardly shared at all. I rea=3D> >lize you could also do a sort of "for= >warding", though I'm not sure that Mod=3D> >ula-3 offers all the right capa= >bilities for this. Type forwarding, sure. Bu=3D> >t how about procedure for= >warding? Like nt386\cstdio.i3 fopen =3D3D common\cco=3D> >mmonstdio.i3 fope= >n? And having to duplicate a line per type/procedure is la=3D> >me anyway, = >you KIND OF want "module inheritance". However, if you allow pre=3D> >proce= >ssing based on target, perhaps the need for that goes away.
> > >> >While extern C varargs functions are generally useless in Modula-3, and= > the=3D> >refore extern __cdecl is fairly rare, it DOES occur when you writ= >e little h=3D> >elpers in C, such as for errno.
> > 
> >A good /= >heuristic/ might be to change the default in any directory that has=3D> > n= >o c_source.
> >But it is only heuristic.
> > 
> >Whatever is = >done here, some allowance should probably be made for multiple =3D> >callin= >g conventions in the same file.
> >Switching the default to the overwhel= >ming majority and then annotating the =3D> >minority is reasonable.
> >&= >nbsp;
> >I still believe that silently ignoring calling conventions on a= >ll but NT386=3D> > is VERY reasonable, and that no other platform from here= > on out will ever =3D> >have calling conventions. Esp. not with the same na= >mes. When OS/FOO has the=3D> > FOOAPI calling convention, you can just igno= >re that one on all but target =3D> >OS/FOO. Just as all but NT386 ignore WI= >NAPI. Yes this COULD possibly get ug=3D> >ly something like:
> ><*EXT= >ERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.>> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention= > for all others, calling convention ignored.=3D> >
> > 
> >I rea= >lly believe this is highly highly unlikely to occur, and it is not a t=3D> = >>errible outcome, and this bridge could be crossed in the far off future.R=3D> >>> >The functions that are usually in need of calling conventions ar= >e usually o=3D> >nly present on one system.
> >Perhaps ODBC is an extrem= >ely rare anomaly and the whole issue is nearly non=3D> >existant.
> >Tha= >t could be also.
> >A change just for ODBC is probably not the best, tho= >ugh it is a very small =3D> >safe harmless change (I always say that :) )R>> > 
> > 
> > - Jay

> >> >
ling>> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> = >From: hosking at c=3D> >s.purdue.edu
> Subject: Re: [M3devel] "target sp= >ecific pragmas"?
&=3D> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
>= >; To: darko at darko.org
&g=3D> >t;
> Indeed!
>
> On Fe= >b 11, 2008, at 8:37 PM, Darko wro=3D> >te:
>
> > I think it= >'s not a good idea. I think all platfor=3D> >m specific code
> > = >should be in a separate file. I'd also like t=3D> >o see an option to
&= >gt; > move calling conventions to the makefile r=3D> >ather than in pram= >as to
> > avoid having to duplicate interface f=3D> >iles just to= > have a different
> > calling convention for a differ=3D> >ent pl= >atform.
> >
> > - Darko
> >
> > >= >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >=3D> >;> So I have NOT thought this through.
> >>
> &g= >t;>=3D> > I wonder if "preprocessing" dependent only on "target" is a go= >od
> =3D> >>> idea.
> >>
> >> Somethin= >g like either the =3D> >ability to prefix pragmas with a target,
> &= >gt;> or an "iftarget"=3D> > and "ifnottarget" pragma.
> >>R>> >> Something like=3D> > so:
> >>
> >> = ><* IF_TARGET NT386 *>
> =3D> >>> <* END_IF_TARGET*>= >
> >>
> >>
>=3D> > >> <* IF_TARGET N= >T386 *>
> >> <* END_IF_TARGET*=3D> >>
> >>= > It's a small can of worms.
> >> Where can=3D> > they be placed= >? Only at "global" scope? (ie: toplevel in
> >>=3D> > an inter= >face/module).
> >>
> >> What about IF_OSTY=3D> >PE?= >
> >> What about expressions?
> >> IF_TARGET NT3=3D= >> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
= >>=3D> >; >>
> >> etc.
> >>
> >>= > I don't =3D> >really have enough interest here to work through this,
&= >gt; >> ju=3D> >st sending out the bait...
> >>
> &g= >t;> Obviously this=3D> > was triggered by my happening into the odbc >> >> directory an=3D> >d bringing up ignoring WINAPI on non-NT386= > or
> >> prefixing c=3D> >alling conventions with a target.>> >>
> >> This re=3D> >minds me of an important point= > here however -- nobody else
> >>=3D> >; is going to make the m= >istake of ever having multiple calling
> >=3D> >;> conventions.= > Therefore the generality of prefixing WINAPI with
&g=3D> >t; >> = >NT386: is useless.
> >> Unless Mac68K support is ad=3D> >ded.R>> >>
> >> And here is some rationale even. The=3D> >= > PC and Mac evolved from
> >> "small" systems, where assembly = >=3D> >programming was common, more
> >> people knew more lower= > level=3D> > details and playing games with
> >> calling conve= >ntions was s=3D> >omething anyone could do. Most other
> >> cu= >rrent systems are =3D> >rooted in C programming. Working in C, calling
= >> >> convention=3D> >s are generally in a hidden layer below what = >anyone
> >> think=3D> >s about. Therefore, the smaller number = >of capable people
> >> =3D> >working at that level have the go= >od sense to only have one calling
>=3D> > >> convention. No mo= >re systems will evolve from "small", at least no=3D> >t
> >> w= >ithout having observed this history. Therefore, there =3D> >will no
>= >; >> longer be multiple calling conventions.
> &=3D> >gt;>R>> >> That is my theory at least.
> >>
&g=3D> >t; = >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall=3D= >> > is
> >> only x86
>


Climb to the = >top=3D> > of the charts!=3DA0Play the word scramble challenge with star pow= >er. >=3D3D'http://club.live.com/star_shuffle.aspx?icid=3D3Dstar= >shuffle_wlmailtextlin=3D> >k_jan' target=3D3D'_new'>Play now!> >= >=3D> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Mika good point, I know that, forgot, thanks for = >reminding me.
>  One of the interesting things about Modula-3, or rather anything but= > C and C++, is easy parsing, easy building of other tools.
> 
>Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the p= >kg tree? You know, they can't understand the source tree without understand= >ing m3makefiles.
> 
>I started a little experiment here.
>I added m3-libs/m3core/src/C/common/Cstdio.i3.
>This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386.
>I'm thinking either:
>   a) I'm not quite on base and just fork it per-target, as it wa= >s
   b) provide a little bit of C code with #ifdefs, like making th= >e SEEK_* constants into VARs and using C to initialize them. That's a bit o= >f a downer though, since constants ought to be constants.
>   c) factor it somehow as I was alluding, like, well, again I'm = >not sure Modula-3 has what I'd want here, but at least for types and consta= >nts, you can push the non-portable stuff into Ctargetstdio.i3 and then expo= >se them in Cstdio.i3, forking only Ctargetstdio.i.
> 
>I'll explain so I can get my question in. :)
> 
>I understand, say:
> 
>Ctargetstdio.i3 (* one of these per target, with not much content *) <= >BR> >CONST
>  SEEK_CUR =3D ..; (* target specific probably *)
>  SEEK_SET =3D ..; ditto
>  SEEK_END =3D ..; ditto 
>TYPE
>  FOO =3D ... ditto 
> 
>Cstdio.i3 (* portable *)
> CONST
>  SEEK_CUR =3D Ctargetstdio.SEEK_CUR;
>  SEEK_SET =3D Ctargetstdio.SEEK_SET;
>  SEEK_END =3D Ctargetstdio.SEEK_END;
>TYPE
>  FOO =3D Ctargetstdio.FOO;
> 
>FILE =3D UNTRACED REF RECORD END;
> 
><extern> procedure fopen(a: const_char_star; b: const_char_star): FIL= >E;
> 
>It is tedious but I believe it works.
>It'd be nice, I think, if every symbol in one interface could be autom= >atically aliases/exposed in another.
>  At least for this purpose, maybe not for any other. I'm speculating = >here, so please respond kindly. :)
>The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place.
> 
>However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another.
>Nevermind for now how you can portably call it.
> 
>Ctargetstdio.i3 (* one of these for every target, but another question in&n= >bsp;a sec ... *)
> 
><extern> PROCEDURE seeksomething(a: off_t);  let's say it is int= > on some platforms.
> 
>Cstdio.i3 (* the portable one *)
> 
>seeksomething =3D Ctargetstdio.seeksomething;    does this w= >ork? I should try it out, read the docs.
> 
>But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int.
>It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants.
>You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE).
>OS_TYPE implies less work, nice.
> 
>Perhaps concatening stuff in arbitrary way with Quake really is the way?> >It seems almost sarcastic, but perhaps not.
> 
>As long as the pkg store is easily parsed?
>(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..)
> 
>But for that matter --- <IF_TARGET> could be processed by the compile= >r and result in a file with it already accounted for and ship that. Isn't t= >hat just as good? EXCEPT that more thought would have to go into the spec, = >whereas m3makefile is already a general purpose system that anyone can do a= >nything with?
> 
>??
> 
> - Jay

> >
>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] "target specific pragmas"?
> Date: Tue, 12 Feb 20= >08 04:56:02 -0800
> From: mika at async.caltech.edu
>
> >> Can you just generate the Modula-3 code you want using a Python
&g= >t; script or COBOL or whatever you like instead of trying to foist
> = >preprocessing nastiness on innocent users of high-level Modula-3?
> <= >BR>> Preprocessing is super nasty. It's not just a question of human
= >> readability. m3tk has to be able to read the code, too. I should
&g= >t; be able to write a program that reads in (using m3tk) an arbitrary
&g= t; Modula-3 interface and understands it to the point that it can
> g= >enerate Network Object stubs, inter-language call stubs, etc. The
> s= >tubs should ALSO be human- and m3tk-readable after the transformation!
&= >gt; This should work even if the programmer has been very "clever" in
&g= >t; his use of Modula-3 constructs. (Just try getting something like
>= > that to work with C or C++... it's hopeless once the preprocessor
> = >gets involved, and possibly before.)
>
> Also if I may make a = >little request, if at all possible, please try
> not to break binary = >compatibility with gcc-compiled C and Fortran
> on NT386GNU (not sure= > if your ideas about calling conventions could
> possibly do that...)= >
>
> Mika
>
> Jay writes:
> >--_8b04f633= >-e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/plain; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> >I insist that it depends.
> >Putting every p= >latform-specific piece of code in its own file/directory can=3D
> >= >; lead to mass duplication of nearly identical code.
> >Sometimes = >an #if here or there goes very far in /improving/ code maintainab=3D
>= >; >ility.
> >A lot of #if here there and everywhere of course c= >an have the opposite effe=3D
> >ct.
> >And I realize if y= >ou were to drop support for a target, it is easier to fin=3D
> >d/= >delete files/directories than #ifs, but I don't think that's a good enoug= >=3D
> >h reason to sway the decision.
> >It goes both way= >s.
> >=3D20
> >Yes, you could endeavor factor things down= > so that everything common is in =3D
> >common, and everything not= >-common is in platform-specific. But this is inad=3D
> >equate I t= >hink. The tail is wagging the dog unnecessarily I think. If my co=3D
>= >; >de very nearly all goes together, don't make me separate it. Also som= >etimes=3D
> > a different factoring is "encouraged" for other reas= >ons, to match someone =3D
> >else's factoring. Look at the C*.i3 f= >iles. They actually can be almost all =3D
> >be nearly the same, y= >et they are hardly shared at all. I realize you could =3D
> >also = >do a sort of "forwarding", though I'm not sure that Modula-3 offers al=3DR>> >l the right capabilities for this. Type forwarding, sure. But ho= >w about pro=3D
> >cedure forwarding? Like nt386\cstdio.i3 fopen = >=3D3D common\ccommonstdio.i3 fo=3D
> >pen? And having to duplicate= > a line per type/procedure is lame anyway, you =3D
> >KIND OF want= > "module inheritance". However, if you allow preprocessing base=3D
> = >>d on target, perhaps the need for that goes away.
> >=3D20
= >> >While extern C varargs functions are generally useless in Modula-3= >, and the=3D
> >refore extern __cdecl is fairly rare, it DOES occu= >r when you write little h=3D
> >elpers in C, such as for errno.>> >=3D20
> >A good /heuristic/ might be to change the defau= >lt in any directory that has=3D
> > no c_source.
> >But i= >t is only heuristic.
> >=3D20
> >Whatever is done here, s= >ome allowance should probably be made for multiple =3D
> >calling = >conventions in the same file.
> >Switching the default to the over= >whelming majority and then annotating the =3D
> >minority is reaso= >nable.
> >=3D20
> >I still believe that silently ignoring= > calling conventions on all but NT386=3D
> > is VERY reasonable, a= >nd that no other platform from here on out will ever =3D
> >have c= >alling conventions. Esp. not with the same names. When OS/FOO has the=3D>> > FOOAPI calling convention, you can just ignore that one on all b= >ut target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes = >this COULD possibly get ug=3D
> >ly something like:
> >&l= >t;*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI= > ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One= > True Calling Convention for all others, calling convention ignored.
>= >; >=3D20
> >I really believe this is highly highly unlikely to = >occur, and it is not a t=3D
> >errible outcome, and this bridge co= >uld be crossed in the far off future.
> >The functions that are us= >ually in need of calling conventions are usually o=3D
> >nly prese= >nt on one system.
> >Perhaps ODBC is an extremely rare anomaly and= > the whole issue is nearly non=3D
> >existant.
> >That co= >uld be also.
> >A change just for ODBC is probably not the best, t= >hough it is a very small =3D
> >safe harmless change (I always say= > that :) )
> >=3D20
> >=3D20
> > - Jay
> &= >gt;
> >
> >
> >> CC: jayk123 at hotmail.com; m3d= >evel at elegosoft.com> From: hosking at cs.purdue.e=3D
> >du> Subj= >ect: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=3DR>> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> &= >gt; On Feb 11, 2008, at 8:=3D
> >37 PM, Darko wrote:> > >= > I think it's not a good idea. I think all platform=3D
> > specifi= >c code > > should be in a separate file. I'd also like to see an op= >=3D
> >tion to > > move calling conventions to the makefile = >rather than in pramas =3D
> >to > > avoid having to duplicat= >e interface files just to have a different >=3D
> > > callin= >g convention for a different platform.> >> > - Darko> >&g= >t; >> > On 1=3D
> >2/02/2008, at 12:21 PM, Jay wrote:>= > >> >> So I have NOT thought this throug=3D
> >h.> = >>>> >> I wonder if "preprocessing" dependent only on "target= >" is a good=3D
> > > >> idea.> >>> >> S= >omething like either the ability to prefix pragmas wit=3D
> >h a t= >arget, > >> or an "iftarget" and "ifnottarget" pragma.> >>= >;> >> Somethi=3D
> >ng like so:> >>> >>= > <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >= >>> >>> >=3D
> >> <* IF_TARGET NT386 *>&= >gt; >> <* END_IF_TARGET*>> >> It's a small can of worm= >=3D
> >s.> >> Where can they be placed? Only at "global" = >scope? (ie: toplevel in >=3D
> > >> an interface/module).= >> >>> >> What about IF_OSTYPE?> >> What about ex= >pr=3D
> >essions?> >> IF_TARGET NT386 OR NTAMD64> >= >>> >> IF_TARGET STARTS(NT)> >>> >=3D
> >= >;> etc.> >>> >> I don't really have enough interest he= >re to work through thi=3D
> >s, > >> just sending out the= > bait...> >>> >> Obviously this was triggered b=3D
>= >; >y my happening into the odbc > >> directory and bringing up = >ignoring WINAPI=3D
> > on non-NT386 or > >> prefixing cal= >ling conventions with a target.> >>> >> =3D
> >T= >his reminds me of an important point here however -- nobody else > >&= >gt; is g=3D
> >oing to make the mistake of ever having multiple ca= >lling > >> conventions. =3D
> >Therefore the generality o= >f prefixing WINAPI with > >> NT386: is useless.> =3D
> &g= >t;>> Unless Mac68K support is added.> >>> >> And he= >re is some rationale even.=3D
> > The PC and Mac evolved from >= > >> "small" systems, where assembly programmi=3D
> >ng was c= >ommon, more > >> people knew more lower level details and playing = >g=3D
> >ames with > >> calling conventions was something = >anyone could do. Most othe=3D
> >r > >> current systems a= >re rooted in C programming. Working in C, calling >=3D
> > >= >> conventions are generally in a hidden layer below what anyone > >= >;> thin=3D
> >ks about. Therefore, the smaller number of capabl= >e people > >> working at t=3D
> >hat level have the good = >sense to only have one calling > >> convention. No =3D
> >= >;more systems will evolve from "small", at least not > >> without = >having obs=3D
> >erved this history. Therefore, there will no >= > >> longer be multiple callin=3D
> >g conventions.> >&= >gt;> >> That is my theory at least.> >>> >> Oh, = >Windows does=3D
> > also have __thiscall and __clrcall. __thiscall= > is > >> only x86>=3D20
> >___________________________= >______________________________________
> >Climb to the top of the = >charts!=3DA0Play the word scramble challenge with sta=3D
> >r powe= >r.
> >http://club.live.com/star_shuffle.aspx?icid=3D3Dstarshuffle_= >wlmailtextlink_ja=3D
> >n=3D
> >
> >--_8b04f633-= >e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/html; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> ><html>
> ><head>
> ><= >;style>
> >.hmmessage P
> >{
> >margin:0px;R>> >padding:0px
> >}
> >body.hmmessage
> >= >;{
> >FONT-SIZE: 10pt;
> >FONT-FAMILY:Tahoma
> >= >}
> ></style>
> ></head>
> ><body= > class=3D3D'hmmessage'>I insist that it depends.<BR>
> >P= >utting every platform-specific piece of code in its own file/directory can= >=3D
> > lead to mass duplication of nearly identical code.<BR&g= >t;
> >Sometimes an #if here or there goes very far in /improving/ = >code maintainab=3D
> >ility.<BR>
> >A lot of #if he= >re there and everywhere of course can have the opposite effe=3D
> >= >;ct.<BR>
> >And I realize if you were to drop support for a = >target, it is easier to fin=3D
> >d/delete files/directories than = >#ifs, but I don't think that's a good enoug=3D
> >h reason to sway= > the decision.<BR>
> >It goes both ways.<BR>
> &= >gt;&nbsp;<BR>
> >Yes, you could endeavor&nbsp;factor= > things down so that everything common i=3D
> >s in common, and ev= >erything not-common is in platform-specific. But this is=3D
> > in= >adequate I think. The tail is wagging the dog unnecessarily I think. If =3D= >
> >my code very nearly all goes together, don't make me&nbsp;= >separate it.&nbsp=3D
> >;Also sometimes a different factoring = >is "encouraged" for other reasons, to=3D
> > match someone else's = >factoring. Look at the C*.i3 files. They actually can=3D
> > be al= >most all be nearly the same, yet they are hardly shared at all. I rea=3D>> >lize you could also do a sort of "forwarding", though I'm not sur= >e that Mod=3D
> >ula-3 offers all the right capabilities for this.= > Type forwarding, sure. Bu=3D
> >t how about procedure forwarding?= > Like nt386\cstdio.i3 fopen =3D3D common\cco=3D
> >mmonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is la=3D
> >= >;me anyway, you KIND OF want "module inheritance". However, if you allow pr= >e=3D
> >processing based on target, perhaps the need for that goes= > away.<BR>
> >&nbsp;<BR>
> >While extern = >C varargs functions are generally useless in Modula-3, and the=3D
> &= >gt;refore extern __cdecl is fairly rare, it DOES occur when you write littl= >e h=3D
> >elpers in C, such as for errno.<BR>
> >&a= >mp;nbsp;<BR>
> >A good /heuristic/ might be to change the de= >fault in any directory that has=3D
> > no c_source.<BR>
&= >gt; >But it is only heuristic.<BR>
> >&nbsp;<BR>= >;
> >Whatever is done here, some allowance should probably be made= > for multiple =3D
> >calling conventions in the same file.<BR&g= >t;
> >Switching the default to the overwhelming majority and then = >annotating the =3D
> >minority is reasonable.<BR>
> &g= >t;&nbsp;<BR>
> >I still believe that silently ignoring c= >alling conventions on all but NT386=3D
> > is VERY reasonable, and= > that no other platform from here on out will ever =3D
> >have cal= >ling conventions. Esp. not with the same names. When OS/FOO has the=3D
&= >gt; > FOOAPI calling convention, you can just ignore that one on all but= > target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes th= is COULD possibly get ug=3D
> >ly something like:<BR>
>= >; >&lt;*EXTERN FOOAPI WINAPI*&gt; fopen();<BR>
> >= >;FOOAPI for OS/FOO, WINAPI ignored.<BR>
> >WINAPI for NT386,= > FOOAPI ignored.<BR>
> >The One True Calling Convention for = >all others, calling convention ignored.=3D
> ><BR>
> &= >gt;&nbsp;<BR>
> >I really believe this is highly highly = >unlikely to occur, and it is not a t=3D
> >errible outcome, and th= >is bridge could be crossed in the far off future.<BR=3D
> >>= >
> >The functions that are usually in need of calling conventions = >are usually o=3D
> >nly present on one system.<BR>
> &= >gt;Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly = >non=3D
> >existant.<BR>
> >That could be also.<B= >R>
> >A change just for ODBC is probably not the best, though i= >t is a very small =3D
> >safe harmless change (I always say that := >) )<BR>
> >&nbsp;<BR>
> >&nbsp;<BR= >>
> >&nbsp;- Jay<BR><BR>
> >
> &= >gt;<HR id=3D3DstopSpelling>
> ><BR>
> >&g= >t; CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>&gt; From: h= >osking at c=3D
> >s.purdue.edu<BR>&gt; Subject: Re: [M3deve= >l] "target specific pragmas"?<BR>&=3D
> >gt; Date: Mon, = >11 Feb 2008 21:08:46 -0500<BR>&gt; To: darko at darko.org<BR>&= >amp;g=3D
> >t; <BR>&gt; Indeed!<BR>&gt; <BR= >>&gt; On Feb 11, 2008, at 8:37 PM, Darko wro=3D
> >te:<B= >R>&gt; <BR>&gt; &gt; I think it's not a good idea. I t= >hink all platfor=3D
> >m specific code <BR>&gt; &gt;= > should be in a separate file. I'd also like t=3D
> >o see an opti= >on to <BR>&gt; &gt; move calling conventions to the makefile = >r=3D
> >ather than in pramas to <BR>&gt; &gt; avoid = >having to duplicate interface f=3D
> >iles just to have a differen= >t <BR>&gt; &gt; calling convention for a differ=3D
> &g= >t;ent platform.<BR>&gt; &gt;<BR>&gt; &gt; - Dar= >ko<BR>&gt; &gt;<BR>&gt; &gt;<B=3D
> &g= >t;R>&gt; &gt; On 12/02/2008, at 12:21 PM, Jay wrote:<BR>&a= >mp;gt; &gt;<BR>&gt; &gt=3D
> >;&gt; So I hav= >e NOT thought this through.<BR>&gt; &gt;&gt;<BR>&am= >p;gt; &gt;&gt;=3D
> > I wonder if "preprocessing" dependen= >t only on "target" is a good <BR>&gt; =3D
> >&gt;&am= >p;gt; idea.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&a= >mp;gt; Something like either the =3D
> >ability to prefix pragmas = >with a target, <BR>&gt; &gt;&gt; or an "iftarget"=3D
&= >gt; > and "ifnottarget" pragma.<BR>&gt; &gt;&gt;<BR= >>&gt; &gt;&gt; Something like=3D
> > so:<BR>&= >amp;gt; &gt;&gt;<BR>&gt; &gt;&gt; &lt;* IF_TA= >RGET NT386 *&gt;<BR>&gt; =3D
> >&gt;&gt; &am= >p;lt;* END_IF_TARGET*&gt;<BR>&gt; &gt;&gt;<BR>&= >amp;gt; &gt;&gt;<BR>&gt;=3D
> > &gt;&gt;= > &lt;* IF_TARGET NT386 *&gt;<BR>&gt; &gt;&gt; &am= >p;lt;* END_IF_TARGET*=3D
> >&gt;<BR>&gt; &gt;&am= >p;gt; It's a small can of worms.<BR>&gt; &gt;&gt; Where c= >an=3D
> > they be placed? Only at "global" scope? (ie: toplevel in= > <BR>&gt; &gt;&gt;=3D
> > an interface/module).&= >lt;BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; What = >about IF_OSTY=3D
> >PE?<BR>&gt; &gt;&gt; What ab= >out expressions?<BR>&gt; &gt;&gt; IF_TARGET NT3=3D
>= >; >86 OR NTAMD64<BR>&gt; &gt;&gt;<BR>&gt; &a= >mp;gt;&gt; IF_TARGET STARTS(NT)<BR>&gt=3D
> >; &= >gt;&gt;<BR>&gt; &gt;&gt; etc.<BR>&gt; &= >gt;&gt;<BR>&gt; &gt;&gt; I don't =3D
> >real= >ly have enough interest here to work through this, <BR>&gt; &= >gt;&gt; ju=3D
> >st sending out the bait...<BR>&gt; = >&gt;&gt;<BR>&gt; &gt;&gt; Obviously this=3D
&g= >t; > was triggered by my happening into the odbc <BR>&gt; &= >;gt;&gt; directory an=3D
> >d bringing up ignoring WINAPI on n= >on-NT386 or <BR>&gt; &gt;&gt; prefixing c=3D
> >= >alling conventions with a target.<BR>&gt; &gt;&gt;<BR&= >gt;&gt; &gt;&gt; This re=3D
> >minds me of an importan= >t point here however -- nobody else <BR>&gt; &gt;&gt=3DR>> >; is going to make the mistake of ever having multiple calling &= >lt;BR>&gt; &gt=3D
> >;&gt; conventions. Therefore t= >he generality of prefixing WINAPI with <BR>&g=3D
> >t; &= >amp;gt;&gt; NT386: is useless.<BR>&gt; &gt;&gt; Unles= >s Mac68K support is ad=3D
> >ded.<BR>&gt; &gt;&g= >t;<BR>&gt; &gt;&gt; And here is some rationale even. The= >=3D
> > PC and Mac evolved from <BR>&gt; &gt;&gt= >; "small" systems, where assembly =3D
> >programming was common, m= >ore <BR>&gt; &gt;&gt; people knew more lower level=3D
= >> > details and playing games with <BR>&gt; &gt;&gt= >; calling conventions was s=3D
> >omething anyone could do. Most o= >ther <BR>&gt; &gt;&gt; current systems are =3D
> &g= >t;rooted in C programming. Working in C, calling <BR>&gt; &gt= >;&gt; convention=3D
> >s are generally in a hidden layer below= > what anyone <BR>&gt; &gt;&gt; think=3D
> >s abo= >ut. Therefore, the smaller number of capable people <BR>&gt; &= >;gt;&gt; =3D
> >working at that level have the good sense to o= >nly have one calling <BR>&gt;=3D
> > &gt;&gt; co= >nvention. No more systems will evolve from "small", at least no=3D
> = >>t <BR>&gt; &gt;&gt; without having observed this hist= >ory. Therefore, there =3D
> >will no <BR>&gt; &gt;&a= >mp;gt; longer be multiple calling conventions.<BR>&gt; &=3DR>> >gt;&gt;<BR>&gt; &gt;&gt; That is my theory= > at least.<BR>&gt; &gt;&gt;<BR>&g=3D
> &g= >t;t; &gt;&gt; Oh, Windows does also have __thiscall and __clrcall. = >__thiscall=3D
> > is <BR>&gt; &gt;&gt; only x86&= >lt;BR>&gt; <BR><BR><br /><hr />Climb to the = >top=3D
> > of the charts!=3DA0Play the word scramble challenge wit= >h star power. <a href=3D
> >=3D3D'http://club.live.com/star_shu= >ffle.aspx?icid=3D3Dstarshuffle_wlmailtextlin=3D
> >k_jan' target= >=3D3D'_new'>Play now!</a></body>
> ></html>= >=3D
> >
> >--_8b04f633-e2a4-411d-940a-739ab79b0616_--
= >

Climb to the top of the charts!=A0Play the word scramble ch= >allenge with star power. icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now! >= > >--_91974b83-e297-4ab9-ba44-e888f600b934_-- From mika at async.caltech.edu Tue Feb 12 22:27:15 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:27:15 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 14:02:23 GMT." Message-ID: <200802122127.m1CLRFi0007370@camembert.async.caltech.edu> Jay writes: >Mika your switch example, besides being invalid C++, is just not fair. >I don't think people even think to write their code like that. >Introducing variables at the top of a switch is rare, esp. initializing the= >m. The example didn't come out of nowhere. I once, a very long time ago, being a not completely competent C programmer, wrote a program like that and spent quite a while debugging it before I realized that the initializations weren't being called. I think I was thinking that initializations are like Fortran DATA statements, or at least should be, in any civilized programming language. If you're extending the stack frame to make room for the declared variables, shouldn't you be calling the initialization code, too? Apparently not... Another way of looking at it is that it was just one of those bizarre little bugs that led me to program in Modula-3. Actually, I remember what finally drove me over the edge. I had written a program to make plots of large VLSI chips at very high resolution (300+ megapixel) using alpha blending, etc., and it was working wonderfully (for years) on FreeBSD. I tried to port it to Linux (trivial, right?) and discovered that I couldn't write a bug-free generic linked list library in C to save my life. The data structures in the program were a bit tricky because of the size of the database, and the fact that I wanted to run it in a small amount of memory. In those days the custom was you had one server with a large amount of RAM (1GB) and a bunch of workstations with 64 or 128 MB. My goal was to run the program, which could take up to a week each time, on the workstations rather than tying up the server (which was busy with other stuff). After I had finally debugged the last memory problem with my program, I sat down and wrote a bug-free one in about two days in Modula-3, a programming language that I previously just vaguely knew as a "fancier Pascal". Mika From dragisha at m3w.org Tue Feb 12 22:24:55 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:24:55 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: <1202851495.3771.3.camel@faramir.m3w.org> This is new project... and it's pretty drafty, meaning it compiles but it does not run. I sumbitted this because it looks like some obscure (underreported?) error to me. Compiler I do use is pretty stable and build lots of my other apps. On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: > Did something change in m3middle/m3front lately? > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > > > % cm3 > > --- building in ../LINUXLIBC6 --- > > > > new source -> compiling Connection.i3 > > new source -> compiling Connection.m3 > > new source -> compiling PDU.i3 > > new source -> compiling PDU.m3 > > "../src/PDU.m3", line 107: warning: not used (len) > > "../src/PDU.m3", line 104: warning: not used (b) > > "../src/PDU.m3", line 116: warning: open array passed by value (o) > > "../src/PDU.m3", line 118: warning: not used (cStr) > > "../src/PDU.m3", line 116: warning: not used (b) > > "../src/PDU.m3", line 116: warning: not used (o) > > "../src/PDU.m3", line 160: warning: not used (c) > > "../src/PDU.m3", line 59: warning: not used (GetInt) > > 8 warnings encountered > > new source -> compiling SMPP.m3 > > "../src/SMPP.m3", line 1: 4 code generation errors > > 1 error encountered > > compilation failed => not building program "smpp" > > Fatal Error: package build failed > > > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From wagner at elegosoft.com Tue Feb 12 23:17:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:17:22 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Message-ID: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Quoting Olaf Wagner : > the builds I started again this morning before leaving home seem to > have succeeded again. I don't understand why compilation with the > latest sources on my own system was broken though; I'll have to > check that tonight. Just one more short followup on this. When I got home, I updated to the latest sources again and ran do-cm3-core.sh. Again, everything compiled, but the executable crashed immediately. I then removed all derived files (realclean) and built again, and this time it worked. So the changes made within the last two days must have touched a subtle dependency of compiler and runtime that the builder does not know or detect. I'd like to understand it better, but it is probably too much effort to isolate all the changes and test them one by one. Sometimes it's just easier to use realclean :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 12 23:22:45 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:22:45 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Quoting Dragi?a Duri? : > This is new project... and it's pretty drafty, meaning it compiles but > it does not run. I sumbitted this because it looks like some obscure > (underreported?) error to me. > > Compiler I do use is pretty stable and build lots of my other apps. > > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >> Did something change in m3middle/m3front lately? >> >> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >> >> > % cm3 >> > --- building in ../LINUXLIBC6 --- [...] >> > "../src/SMPP.m3", line 1: 4 code generation errors >> > 1 error encountered If you could try and post a minimal example that provokes this failure, I'm sure someone on this list can help to solve the problem. Just the lines above provide too little information though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Feb 12 22:35:12 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:35:12 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B1B848.1E75.00D7.1@scires.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> Message-ID: <1202852112.3771.13.camel@faramir.m3w.org> What we _maybe_ can do... is to make some special, preprocessable source form, which some quake command can parse into multiple files in their folders. And these file can be compiled later...Kind of how generic works. But, as current system works, and it does it very well, and as only case where we really need this is Windows... most Unices being or becoming POSIX... I don't see it's smart to spend resources on becoming more C... Esp when "founding fathers" made it so good and so much non-C :). If we really need to make some approach to "their world", it's much better to work on interoperability issues and thus cement our first-class-citizen language status even more. dd On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > Jay: > > My understanding of Modula-3 is that rather than cluttering up the > source code with a bunch of preprocessor directives to deal with the > various changes needed by various platforms, a separate source file is > used for platforms whose implementation must diverge. The m3makefile > is used to control the selection of these platform sources at build > time. I like this approach much better. > > Regards, > Randy > > >>> Jay 2/11/2008 8:21 PM >>> > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, or > an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in an > interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling conventions. > Therefore the generality of prefixing WINAPI with NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew more > lower level details and playing games with calling conventions was > something anyone could do. Most other current systems are rooted in C > programming. Working in C, calling conventions are generally in a > hidden layer below what anyone thinks about. Therefore, the smaller > number of capable people working at that level have the good sense to > only have one calling convention. No more systems will evolve from > "small", at least not without having observed this history. Therefore, > there will no longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 -- Dragi?a Duri? From jayk123 at hotmail.com Tue Feb 12 23:23:30 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:23:30 +0000 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: >From reading the code easily/quickly, this is strange. > > > "../src/SMPP.m3", line 1: 4 code generation errors should be preceded by other sorts of errors. And they all/almost all sound "like internal errors", like assertion failures in m3middle. In particular one of: m3-sys\m3middle\src\M3CG_Check.m3(190):PROCEDURE PutErr (u: U; a, b, c: TEXT := NIL) =m3-sys\m3middle\src\M3CG_Check.m3(194): END PutErr;m3-sys\m3middle\src\M3CG_Check.m3(242): PutErr (self, "bad stack: expected [ ",m3-sys\m3middle\src\M3CG_Check.m3(261): ELSE PutErr (self, "stack overflow");m3-sys\m3middle\src\M3CG_Check.m3(274): PutErr (self, "non-empty stack: ", Stack_Dump (self));m3-sys\m3middle\src\M3CG_Check.m3(382): PutErr (self, "redefined runtime proc: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(391): PutErr (self, "redefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(400): PutErr (self, "undefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(410): PutErr (self, "NIL variable");m3-sys\m3middle\src\M3CG_Check.m3(432): PutErr (self, "temporary reused while live!");m3-sys\m3middle\src\M3CG_Check.m3(446): PutErr (self, "temp freed twice");m3-sys\m3middle\src\M3CG_Check.m3(458): PutErr (self, "nested static initialization");m3-sys\m3middle\src\M3CG_Check.m3(470): ELSE PutErr (self, "missing begin_init");m3-sys\m3middle\src\M3CG_Check.m3(477): IF (self.in_init <= 0) THEN PutErr (self, "missing begin_init") END;m3-sys\m3middle\src\M3CG_Check.m3(480): ELSE PutErr (self, "decreasing offsets");m3-sys\m3middle\src\M3CG_Check.m3(532): PutErr (self, "NIL procedure");m3-sys\m3middle\src\M3CG_Check.m3(540): PutErr (self, "nested procedure declaration");m3-sys\m3middle\src\M3CG_Check.m3(551): ELSE PutErr (self, "missing begin_procedure");m3-sys\m3middle\src\M3CG_Check.m3(554): PutErr (self, "missing end_blocks: ", Int (self.block_count));m3-sys\m3middle\src\M3CG_Check.m3(562): PutErr (self, "temp not freed, created on line ", Int (line));m3-sys\m3middle\src\M3CG_Check.m3(574): PutErr (self, "begin_block not in procedure");m3-sys\m3middle\src\M3CG_Check.m3(586): ELSE PutErr (self, "missing begin_block");m3-sys\m3middle\src\M3CG_Check.m3(604): PutErr (self, "undefined label: ", Int (l));m3-sys\m3middle\src\M3CG_Check.m3(716): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(724): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(739): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(747): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(775): PutErr (self, "floating-point literal doesn't match type");m3-sys\m3middle\src\M3CG_Check.m3(1231): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1242): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1251): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1260): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1268): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1279): ELSE PutErr (self, "missing start_call");34 occurrence(s) have been found. - Jay > From: dragisha at m3w.org> To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 22:24:55 +0100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] wtf "code generation errors"?> > This is new project... and it's pretty drafty, meaning it compiles but> it does not run. I sumbitted this because it looks like some obscure> (underreported?) error to me.> > Compiler I do use is pretty stable and build lots of my other apps.> > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote:> > Did something change in m3middle/m3front lately?> > > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote:> > > > > % cm3> > > --- building in ../LINUXLIBC6 ---> > >> > > new source -> compiling Connection.i3> > > new source -> compiling Connection.m3> > > new source -> compiling PDU.i3> > > new source -> compiling PDU.m3> > > "../src/PDU.m3", line 107: warning: not used (len)> > > "../src/PDU.m3", line 104: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: open array passed by value (o)> > > "../src/PDU.m3", line 118: warning: not used (cStr)> > > "../src/PDU.m3", line 116: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: not used (o)> > > "../src/PDU.m3", line 160: warning: not used (c)> > > "../src/PDU.m3", line 59: warning: not used (GetInt)> > > 8 warnings encountered> > > new source -> compiling SMPP.m3> > > "../src/SMPP.m3", line 1: 4 code generation errors> > > 1 error encountered> > > compilation failed => not building program "smpp"> > > Fatal Error: package build failed> > >> > > -- > > > Dragi?a Duri? > > > -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:26:57 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:26:57 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some. Does it happen on birch? Or only FreeBSD? I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this. Ideally it happens on birch, much quicker for me to get into. Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:30:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:30:23 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: I'm still left wondering -- these other language tools -- you run them over the pkg store's shipped implementation files, right? Or at least check the BUILD_DIR for derived *3 files? Or do the tools, like, ignore missing implementations or other "small" problems? If the "forwarding" shown works, that goes very far in solving this problem without stepping on other language tools (again though, depending somewhat on the first question -- except, I just remembered -- a lot of these tools only need the *.i3 files and not the *.m3 files?) - Jay > Subject: Re: [M3devel] "target specific pragmas"?> From: dragisha at m3w.org> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> Date: Tue, 12 Feb 2008 22:35:12 +0100> > What we _maybe_ can do... is to make some special, preprocessable source> form, which some quake command can parse into multiple files in their> folders. And these file can be compiled later...Kind of how generic> works. > > But, as current system works, and it does it very well, and as only case> where we really need this is Windows... most Unices being or becoming> POSIX... I don't see it's smart to spend resources on becoming more C...> Esp when "founding fathers" made it so good and so much non-C :).> > If we really need to make some approach to "their world", it's much> better to work on interoperability issues and thus cement our> first-class-citizen language status even more.> > dd> > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > Jay:> > > > My understanding of Modula-3 is that rather than cluttering up the> > source code with a bunch of preprocessor directives to deal with the> > various changes needed by various platforms, a separate source file is> > used for platforms whose implementation must diverge. The m3makefile> > is used to control the selection of these platform sources at build> > time. I like this approach much better.> > > > Regards,> > Randy> > > > >>> Jay 2/11/2008 8:21 PM >>>> > So I have NOT thought this through.> > > > I wonder if "preprocessing" dependent only on "target" is a good idea.> > > > Something like either the ability to prefix pragmas with a target, or> > an "iftarget" and "ifnottarget" pragma.> > > > Something like so:> > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > > > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > It's a small can of worms.> > Where can they be placed? Only at "global" scope? (ie: toplevel in an> > interface/module).> > > > What about IF_OSTYPE?> > What about expressions?> > IF_TARGET NT386 OR NTAMD64> > > > IF_TARGET STARTS(NT)> > > > etc.> > > > I don't really have enough interest here to work through this, just> > sending out the bait...> > > > Obviously this was triggered by my happening into the odbc directory> > and bringing up ignoring WINAPI on non-NT386 or prefixing calling> > conventions with a target.> > > > This reminds me of an important point here however -- nobody else is> > going to make the mistake of ever having multiple calling conventions.> > Therefore the generality of prefixing WINAPI with NT386: is useless.> > Unless Mac68K support is added.> > > > And here is some rationale even. The PC and Mac evolved from "small"> > systems, where assembly programming was common, more people knew more> > lower level details and playing games with calling conventions was> > something anyone could do. Most other current systems are rooted in C> > programming. Working in C, calling conventions are generally in a> > hidden layer below what anyone thinks about. Therefore, the smaller> > number of capable people working at that level have the good sense to> > only have one calling convention. No more systems will evolve from> > "small", at least not without having observed this history. Therefore,> > there will no longer be multiple calling conventions.> > > > That is my theory at least.> > > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is> > only x86> -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:33:34 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:33:34 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Olaf, Oh, upon closer read, things are ok now? This could still be somehow attributed to my "VAL" change? And once realclean once, build repeatedly, and it never comes back? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 22:26:57 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some.Does it happen on birch? Or only FreeBSD?I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this.Ideally it happens on birch, much quicker for me to get into.Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 23:52:21 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:52:21 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <20080212235221.3l9sf3f9c088gw04@mail.elegosoft.com> Quoting Jay : > Olaf, Oh, upon closer read, things are ok now? This could still be > somehow attributed to my "VAL" change? > And once realclean once, build repeatedly, and it never comes back? It's all ok now, though we have introduced some incompatibility somewhere, and the builder can't find it. It shows up in other errors when trying to build the whole set of packages, for example: === package m3-ui/mgkit === +++ cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ --- building in FreeBSD4 --- Fatal Error: bad version stamps: PlttFrnds.i3 inconsistent opaque object info for type _t1541f475 super type: _te422a136 data: (size: 32, align: 32) method: (size: 0) => PlttFrnds.i3 super type: _te422a136 data: (size: 64, align: 32) method: (size: 0) => RectsVBT.i3 *** execution of cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' failed *** Ideally, such things shouldn't happen with M3, but I'm pretty sure the package will compile from scratch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 00:54:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:54:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: My principle concern is that once we provide C APIs then C will permeate the M3 space more pervasively (both apps and libraries). What happens when I want to bring up a system where there is no C?!?! Consider the SPIN OS perhaps... Maybe I am just being overly fusty... On Feb 12, 2008, at 4:35 PM, Dragi?a Duri? wrote: > What we _maybe_ can do... is to make some special, preprocessable > source > form, which some quake command can parse into multiple files in their > folders. And these file can be compiled later...Kind of how generic > works. > > But, as current system works, and it does it very well, and as only > case > where we really need this is Windows... most Unices being or becoming > POSIX... I don't see it's smart to spend resources on becoming more > C... > Esp when "founding fathers" made it so good and so much non-C :). > > If we really need to make some approach to "their world", it's much > better to work on interoperability issues and thus cement our > first-class-citizen language status even more. > > dd > > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >> Jay: >> >> My understanding of Modula-3 is that rather than cluttering up the >> source code with a bunch of preprocessor directives to deal with the >> various changes needed by various platforms, a separate source >> file is >> used for platforms whose implementation must diverge. The m3makefile >> is used to control the selection of these platform sources at build >> time. I like this approach much better. >> >> Regards, >> Randy >> >>>>> Jay 2/11/2008 8:21 PM >>> >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, or >> an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in an >> interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, just >> sending out the bait... >> >> Obviously this was triggered by my happening into the odbc directory >> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >> conventions with a target. >> >> This reminds me of an important point here however -- nobody else is >> going to make the mistake of ever having multiple calling >> conventions. >> Therefore the generality of prefixing WINAPI with NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from "small" >> systems, where assembly programming was common, more people knew more >> lower level details and playing games with calling conventions was >> something anyone could do. Most other current systems are rooted in C >> programming. Working in C, calling conventions are generally in a >> hidden layer below what anyone thinks about. Therefore, the smaller >> number of capable people working at that level have the good sense to >> only have one calling convention. No more systems will evolve from >> "small", at least not without having observed this history. >> Therefore, >> there will no longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Feb 13 00:56:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:56:31 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Message-ID: <15AF5E94-4440-450A-BFC4-9553CEB25A03@cs.purdue.edu> Certainly, anything provoking an m3middle error of this kind needs fixing. Can we see a code fragment (and preferably a compilable test case) that generates this error? On Feb 12, 2008, at 5:22 PM, Olaf Wagner wrote: > Quoting Dragi?a Duri? : >> This is new project... and it's pretty drafty, meaning it compiles >> but >> it does not run. I sumbitted this because it looks like some obscure >> (underreported?) error to me. >> >> Compiler I do use is pretty stable and build lots of my other apps. >> >> On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >>> Did something change in m3middle/m3front lately? >>> >>> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >>> >>> > % cm3 >>> > --- building in ../LINUXLIBC6 --- > [...] >>> > "../src/SMPP.m3", line 1: 4 code generation errors >>> > 1 error encountered > > If you could try and post a minimal example that provokes this > failure, I'm sure someone on this list can help to solve the problem. > Just the lines above provide too little information though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Wed Feb 13 00:57:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:57:19 -0500 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <562DD220-6570-4F79-85D9-85F74092A9F9@cs.purdue.edu> I am betting the change to MUTEX definition broke depedent code. On Feb 12, 2008, at 5:17 PM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> the builds I started again this morning before leaving home seem to >> have succeeded again. I don't understand why compilation with the >> latest sources on my own system was broken though; I'll have to >> check that tonight. > > Just one more short followup on this. When I got home, I updated > to the latest sources again and ran do-cm3-core.sh. Again, everything > compiled, but the executable crashed immediately. I then removed > all derived files (realclean) and built again, and this time it > worked. So the changes made within the last two days must have > touched a subtle dependency of compiler and runtime that the builder > does not know or detect. I'd like to understand it better, but it is > probably too much effort to isolate all the changes and test them > one by one. Sometimes it's just easier to use realclean :-/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 01:37:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 16:37:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 18:54:50 EST." Message-ID: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> This is also an excellent reason not to permit "interfaces" to C code inlined into MODULEs. Interfaces are the contract that the implementation has to live up to. Ok, so it happens that under operating system X on architecture Y, the easiest way to implement the interface is to call a C function that "just happens" to have the correct interface. But on another system, which either isn't built in C or where the function doesn't exist, it might be convenient to implement the interface in (gasp!) Modula-3! (I use this pattern as follows: on systems where Intel's Fortran compiler is available, compile from assembly (which was generated by ifort). On other systems, the code is implemented in Modula-3.) Mika Tony Hosking writes: >My principle concern is that once we provide C APIs then C will >permeate the M3 space more pervasively (both apps and libraries). >What happens when I want to bring up a system where there is no >C?!?! Consider the SPIN OS perhaps... > >Maybe I am just being overly fusty... > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > >> What we _maybe_ can do... is to make some special, preprocessable >> source >> form, which some quake command can parse into multiple files in their >> folders. And these file can be compiled later...Kind of how generic >> works. >> >> But, as current system works, and it does it very well, and as only >> case >> where we really need this is Windows... most Unices being or becoming >> POSIX... I don't see it's smart to spend resources on becoming more >> C... >> Esp when "founding fathers" made it so good and so much non-C :). >> >> If we really need to make some approach to "their world", it's much >> better to work on interoperability issues and thus cement our >> first-class-citizen language status even more. >> >> dd >> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >>> Jay: >>> >>> My understanding of Modula-3 is that rather than cluttering up the >>> source code with a bunch of preprocessor directives to deal with the >>> various changes needed by various platforms, a separate source >>> file is >>> used for platforms whose implementation must diverge. The m3makefile >>> is used to control the selection of these platform sources at build >>> time. I like this approach much better. >>> >>> Regards, >>> Randy >>> >>>>>> Jay 2/11/2008 8:21 PM >>> >>> So I have NOT thought this through. >>> >>> I wonder if "preprocessing" dependent only on "target" is a good >>> idea. >>> >>> Something like either the ability to prefix pragmas with a target, or >>> an "iftarget" and "ifnottarget" pragma. >>> >>> Something like so: >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> It's a small can of worms. >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an >>> interface/module). >>> >>> What about IF_OSTYPE? >>> What about expressions? >>> IF_TARGET NT386 OR NTAMD64 >>> >>> IF_TARGET STARTS(NT) >>> >>> etc. >>> >>> I don't really have enough interest here to work through this, just >>> sending out the bait... >>> >>> Obviously this was triggered by my happening into the odbc directory >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >>> conventions with a target. >>> >>> This reminds me of an important point here however -- nobody else is >>> going to make the mistake of ever having multiple calling >>> conventions. >>> Therefore the generality of prefixing WINAPI with NT386: is useless. >>> Unless Mac68K support is added. >>> >>> And here is some rationale even. The PC and Mac evolved from "small" >>> systems, where assembly programming was common, more people knew more >>> lower level details and playing games with calling conventions was >>> something anyone could do. Most other current systems are rooted in C >>> programming. Working in C, calling conventions are generally in a >>> hidden layer below what anyone thinks about. Therefore, the smaller >>> number of capable people working at that level have the good sense to >>> only have one calling convention. No more systems will evolve from >>> "small", at least not without having observed this history. >>> Therefore, >>> there will no longer be multiple calling conventions. >>> >>> That is my theory at least. >>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >>> only x86 >> -- >> Dragi??a Duri?? From jayk123 at hotmail.com Wed Feb 13 05:28:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 04:28:41 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix?There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 16:37:43 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > > This is also an excellent reason not to permit "interfaces" to C> code inlined into MODULEs.> > Interfaces are the contract that the implementation has to live up> to. Ok, so it happens that under operating system X on architecture> Y, the easiest way to implement the interface is to call a C function> that "just happens" to have the correct interface. But on another> system, which either isn't built in C or where the function doesn't> exist, it might be convenient to implement the interface in (gasp!)> Modula-3!> > (I use this pattern as follows: on systems where Intel's Fortran> compiler is available, compile from assembly (which was generated> by ifort). On other systems, the code is implemented in Modula-3.)> > Mika> > Tony Hosking writes:> >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps...> >> >Maybe I am just being overly fusty...> >> >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> >> >> What we _maybe_ can do... is to make some special, preprocessable > >> source> >> form, which some quake command can parse into multiple files in their> >> folders. And these file can be compiled later...Kind of how generic> >> works.> >>> >> But, as current system works, and it does it very well, and as only > >> case> >> where we really need this is Windows... most Unices being or becoming> >> POSIX... I don't see it's smart to spend resources on becoming more > >> C...> >> Esp when "founding fathers" made it so good and so much non-C :).> >>> >> If we really need to make some approach to "their world", it's much> >> better to work on interoperability issues and thus cement our> >> first-class-citizen language status even more.> >>> >> dd> >>> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> >>> Jay:> >>>> >>> My understanding of Modula-3 is that rather than cluttering up the> >>> source code with a bunch of preprocessor directives to deal with the> >>> various changes needed by various platforms, a separate source > >>> file is> >>> used for platforms whose implementation must diverge. The m3makefile> >>> is used to control the selection of these platform sources at build> >>> time. I like this approach much better.> >>>> >>> Regards,> >>> Randy> >>>> >>>>>> Jay 2/11/2008 8:21 PM >>>> >>> So I have NOT thought this through.> >>>> >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea.> >>>> >>> Something like either the ability to prefix pragmas with a target, or> >>> an "iftarget" and "ifnottarget" pragma.> >>>> >>> Something like so:> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>>> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>> It's a small can of worms.> >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an> >>> interface/module).> >>>> >>> What about IF_OSTYPE?> >>> What about expressions?> >>> IF_TARGET NT386 OR NTAMD64> >>>> >>> IF_TARGET STARTS(NT)> >>>> >>> etc.> >>>> >>> I don't really have enough interest here to work through this, just> >>> sending out the bait...> >>>> >>> Obviously this was triggered by my happening into the odbc directory> >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling> >>> conventions with a target.> >>>> >>> This reminds me of an important point here however -- nobody else is> >>> going to make the mistake of ever having multiple calling > >>> conventions.> >>> Therefore the generality of prefixing WINAPI with NT386: is useless.> >>> Unless Mac68K support is added.> >>>> >>> And here is some rationale even. The PC and Mac evolved from "small"> >>> systems, where assembly programming was common, more people knew more> >>> lower level details and playing games with calling conventions was> >>> something anyone could do. Most other current systems are rooted in C> >>> programming. Working in C, calling conventions are generally in a> >>> hidden layer below what anyone thinks about. Therefore, the smaller> >>> number of capable people working at that level have the good sense to> >>> only have one calling convention. No more systems will evolve from> >>> "small", at least not without having observed this history. > >>> Therefore,> >>> there will no longer be multiple calling conventions.> >>>> >>> That is my theory at least.> >>>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is> >>> only x86> >> -- > >> Dragi??a Duri?? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:18:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:18:24 +0000 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: >> And I think we should fix it so that that the symbols have full source paths. >> I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. My experience using gdb suggests that the symbols have paths like foo.m3 and/or ../bar.i3 but never "full paths". You can tell gdb where to look for files, it isn't that hard, and it works. However I would really like the paths to be full paths and gdb to automatically show the source. (I'd also like a mode that shows no source and only assembly, switching off and on, presumably I'll find this in the gdb docs; it's pretty stinky that in the absence of source, you have to tell it display/i $pc but oh well...) Now, 1) Do people mind their full paths "leaking" out in binaries they give people? Make the behavior an option here? 2) When such binaries are moved across machines, presumably you are back roughly where you started. Ok. And then the same "fix"? Or does the full paths defeat any sort of search in provided paths? (It's pretty obvious where this leads if you think about the implementation -- they can look for leaf path elements in a list of directories, and they can be super aggressive and do something iterative where they try cutting off an element at a time from the start of the path and append that to each "search path", and furthermore, they can "remember" which prefixes' removal tended to work and skip right to that, however that could also lead to missing other matches, and this all rapidly explodes into many probes for files and not clearly worth it; I've never implemented a debugger but I've been a greedy/whiny user. :) ) I have not at all looked into this but I assume once I do it's not that difficult to fix. It's probably a matter of a small number of strategically placed calls to get the full path to a file. There will be the inevitable issues with the two or more different path syntaxes (essentially, mingwin and cygwin have different syntaxes, though you can setup symlinks easily enough to make them able to share each other's paths). I don't know if it plays into any "fingerprinting", and if so, that could be a total deal breaker. I kind of expect it does not. Not in anything people expect to read/write into pickles. Could be that switching this causes a rebuild of everything. Could be the full and relative paths are needed, like for cm3 -ship to work or something, or for the resulting shipped .m3exports files to work. Could be some of the builtin very well hidden stuff, the quake functions that .m3exports files use need an extra parameter, but maybe not. You know, as long as only m3cg/as get the changed paths and nothing else does... - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:38:17 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:38:17 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: done hours ago, not sure I saw the commitI still find a bit unsatisfactory.. but I guess that's plenty good. :) - Jay > From: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 12:54:15 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay, I *really* dislike the idea that you are putting target-specific > code in a subdirectory labeled Common!> > If I want to search for target-specific stuff I grep for directories > labeled by that target.> > Please, please, please think about the global picture before making > these sorts of local changes!> > Please back this change out and put this where it belongs in cm3/m3- > libs/m3core/src/C/NT386. I am happy to do it for you but I have > other things to do with my time!> > On Feb 12, 2008, at 2:05 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/02/12 14:05:18> >> > Modified files:> > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c> >> > Log message:> > fix (NT386 only)> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:03 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I don't disagree much or care much. But I like seeing my name in lights. :) - Jay > CC: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: $Id$ ?> Date: Tue, 12 Feb 2008 12:43:53 -0500> To: jayk123 at hotmail.com> > The log tells the story much better than random comments in the code.> > On Feb 12, 2008, at 1:18 AM, Jay wrote:> > > I added some files a while ago and someone either complained or > > added them, so I've been adding them since.> >> > - Jay> >> >> > > Date: Tue, 12 Feb 2008 05:20:47 +0000> > > To: m3commit at elegosoft.com> > > From: hosking at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: hosking at birch. 08/02/12 05:20:47> > >> > > Modified files:> > > cm3/m3-sys/cm3/src/: m3makefile> > >> > > Log message:> > > Let's avoid RCS id stuff shall we. Just clutters up the files...> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:55 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:55 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: Sounds good to me! - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] externs in modules instead of interfaces?> Date: Tue, 12 Feb 2008 12:42:57 -0500> To: jayk123 at hotmail.com> > The globals are gross, and not available on other platforms. Let's > just drop them...> > On Feb 12, 2008, at 12:21 PM, Jay wrote:> > > I think I just said this over the weekend, but really, I should be > > able to put in modules and not be forced to put them in an > > interface.> > Look at the cygwin Utime.i3/m3/C.c for example...> > Yeah, it's a workaround, that I'd like to remove, but it could > > easily represent a non-workaround..> > There's no real "interface/module" here, it's just that I wrote > > some of the code in C.> >> > sorry to be such an annoying whiner..but I ran into this multiple > > times over a short span of time...> >> > - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 12:01:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 11:01:51 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> References: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Message-ID: > From: hosking at cs.purdue.edu> > Aren't these all superseded by gettimeofday?> > I say just not support the global variable access.> > Utime.i3 on other platforms does not have these globals. Could be. I don't know this stuff.. They are currently used though. I didn't happen here by chance.. I'll maybe poke around. I guess this is a time to send diffs and get sign off on all platforms. OR fork the file backwards to DateLinuxOld.m3, DateBsdOld.m3, move everyone to it, then fix DateLinux/Bsd to have no data and as people test their platform move forward? And the last guy turn off the lights? (This is a philosophical and real question. The first approach is slower but moves cleanly all at once from good to good. The second approach allows a gradual migration that starts right away and leaves a cluttered history in its wake but arrives at the same place, possibly but not necessarily sooner.) Anyway, my workaround I think is working.. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 13 14:53:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:53:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <7EF4EBB4-D4F2-4964-80C0-78576D0C9812@cs.purdue.edu> On Feb 12, 2008, at 11:28 PM, Jay wrote: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. I think you will meet strong resistance here for precisely the opposite reason that you are arguing. If you want C write in C. From hosking at cs.purdue.edu Wed Feb 13 14:55:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:55:20 -0500 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: These behaviors are derivative of the GNU tools, not CM3 per se. The munged names are understood by m3gdb, which uses them to obtain type information. You don't see the munged name in m3gdb. On Feb 13, 2008, at 5:18 AM, Jay wrote: > >> And I think we should fix it so that that the symbols have full > source paths. > >> I realize they would only be correct on one machine, and > hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and > it works. > > However I would really like the paths to be full paths and gdb to > automatically show the source. > (I'd also like a mode that shows no source and only assembly, > switching off and on, presumably I'll find this in the gdb docs; > it's pretty stinky that in the absence of source, you have to tell > it display/i $pc but oh well...) > > Now, > 1) Do people mind their full paths "leaking" out in binaries they > give people? > Make the behavior an option here? > > 2) When such binaries are moved across machines, presumably you are > back roughly where you started. Ok. > And then the same "fix"? Or does the full paths defeat any sort of > search in provided paths? > (It's pretty obvious where this leads if you think about the > implementation -- they can look for leaf path elements in a list of > directories, and they can be super aggressive and do something > iterative where they try cutting off an element at a time from the > start of the path and append that to each "search path", and > furthermore, they can "remember" which prefixes' removal tended to > work and skip right to that, however that could also lead to > missing other matches, and this all rapidly explodes into many > probes for files and not clearly worth it; I've never implemented a > debugger but I've been a greedy/whiny user. :) ) > > I have not at all looked into this but I assume once I do it's not > that difficult to fix. > It's probably a matter of a small number of strategically placed > calls to get the full path to a file. > There will be the inevitable issues with the two or more different > path syntaxes (essentially, mingwin and cygwin have different > syntaxes, though you can setup symlinks easily enough to make them > able to share each other's paths). > > I don't know if it plays into any "fingerprinting", and if so, that > could be a total deal breaker. > I kind of expect it does not. Not in anything people expect to read/ > write into pickles. > Could be that switching this causes a rebuild of everything. > Could be the full and relative paths are needed, like for cm3 -ship > to work or something, or for the resulting shipped .m3exports files > to work. Could be some of the builtin very well hidden stuff, the > quake functions that .m3exports files use need an extra parameter, > but maybe not. You know, as long as only m3cg/as get the changed > paths and nothing else does... > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From wagner at elegosoft.com Wed Feb 13 14:58:28 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 14:58:28 +0100 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: <20080213145828.npvgox31w8g8k8sw@mail.elegosoft.com> Quoting Jay : > >> And I think we should fix it so that that the symbols have full > source paths. >> I realize they would only be correct on one > machine, and hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and it works. What exactly is the full path of a module? That of your private workspace (assuming you are using overrides for everything) or that in the global package pool (/usr/local/cm3/pkg/...)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 13 18:44:31 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 13 Feb 2008 12:44:31 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B2E62D.1E75.00D7.1@scires.com> Jay: I don't want to be offensive, but quite frankly I'm tired of continually reading your gripes about Modula-3 as a language and your pining for C. This forum is for those people interested in advancing the state of Modula-3. We don't care about C/C++/C#/etc in this forum. Those of us who are M3 zealots for the most part probably would welcome any move to divest CM3 of all underpinnings from the C world. Have you seriously studied the Modula-3 language and used it to build production software? I think some of your comments suggest that you are not a true Modula-3 programmer and that you still cling to the C-way of doing things rather than embracing the Modula-3 way. Now, I do think that most people are interested in improving things and no language is perfect, so any well-thought-out proposal for a change to the language is welcome for consideration, But in this mail list forum, I for one would appreciate less ranting about C and more constructive Modula-3. Truly, I do not want to offend you. Maybe I'm just having a bad day, but I encourage you to try and focus your posts to the advancement of Modula-3. Regards, Randy >>> Jay 2/12/2008 11:28 PM >>> > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix? There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu > Date: Tue, 12 Feb 2008 16:37:43 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "target specific pragmas"? > > > This is also an excellent reason not to permit "interfaces" to C > code inlined into MODULEs. > > Interfaces are the contract that the implementation has to live up > to. Ok, so it happens that under operating system X on architecture > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another > system, which either isn't built in C or where the function doesn't > exist, it might be convenient to implement the interface in (gasp!) > Modula-3! > > (I use this pattern as follows: on systems where Intel's Fortran > compiler is available, compile from assembly (which was generated > by ifort). On other systems, the code is implemented in Modula-3.) > > Mika > > Tony Hosking writes: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps... > > > >Maybe I am just being overly fusty... > > > >On Feb 12, 2008, at 4:35 PM, Dragi?*a Duri?* wrote: > > > >> What we _maybe_ can do... is to make some special, preprocessable > >> source > >> form, which some quake command can parse into multiple files in their > >> folders. And these file can be compiled later...Kind of how generic > >> works. > >> > >> But, as current system works, and it does it very well, and as only > >> case > >> where we really need this is Windows... most Unices being or becoming > >> POSIX... I don't see it's smart to spend resources on becoming more > >> C... > >> Esp when "founding fathers" made it so good and so much non-C :). > >> > >> If we really need to make some approach to "their world", it's much > >> better to work on interoperability issues and thus cement our > >> first-class-citizen language status even more. > >> > >> dd > >> > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > >>> Jay: > >>> > >>> My understanding of Modula-3 is that rather than cluttering up the > >>> source code with a bunch of preprocessor directives to deal with the > >>> various changes needed by various platforms, a separate source > >>> file is > >>> used for platforms whose implementation must diverge. The m3makefile > >>> is used to control the selection of these platform sources at build > >>> time. I like this approach much better. > >>> > >>> Regards, > >>> Randy > >>> > >>>>>> Jay 2/11/2008 8:21 PM >>> > >>> So I have NOT thought this through. > >>> > >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea. > >>> > >>> Something like either the ability to prefix pragmas with a target, or > >>> an "iftarget" and "ifnottarget" pragma. > >>> > >>> Something like so: > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> It's a small can of worms. > >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an > >>> interface/module). > >>> > >>> What about IF_OSTYPE? > >>> What about expressions? > >>> IF_TARGET NT386 OR NTAMD64 > >>> > >>> IF_TARGET STARTS(NT) > >>> > >>> etc. > >>> > >>> I don't really have enough interest here to work through this, just > >>> sending out the bait... > >>> > >>> Obviously this was triggered by my happening into the odbc directory > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling > >>> conventions with a target. > >>> > >>> This reminds me of an important point here however -- nobody else is > >>> going to make the mistake of ever having multiple calling > >>> conventions. > >>> Therefore the generality of prefixing WINAPI with NT386: is useless. > >>> Unless Mac68K support is added. > >>> > >>> And here is some rationale even. The PC and Mac evolved from "small" > >>> systems, where assembly programming was common, more people knew more > >>> lower level details and playing games with calling conventions was > >>> something anyone could do. Most other current systems are rooted in C > >>> programming. Working in C, calling conventions are generally in a > >>> hidden layer below what anyone thinks about. Therefore, the smaller > >>> number of capable people working at that level have the good sense to > >>> only have one calling convention. No more systems will evolve from > >>> "small", at least not without having observed this history. > >>> Therefore, > >>> there will no longer be multiple calling conventions. > >>> > >>> That is my theory at least. > >>> > >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >>> only x86 > >> -- > >> Dragi?*a Duri?* Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Feb 13 19:04:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 13 Feb 2008 12:04:15 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B3311F.4070507@wichita.edu> I haven't tried building it on any form of Windows in a long time, but m3gdb accepts unmangled Modula-3 variable (and procedure and type) names, starting with a module or interface name and supplying a fully- qualified path outside-in with procedure names and anonymous block numbers. Or, if you are stopped at a spot in the code, it will look up unqualified, unmangled names using the language's scope rules from the current point. (Hence my concern about having static links stored.) From there, you can put on additional qualifiers. Naming executable points in the code (e.g. to set breakpoints) works similarly, although that is somewhat different, and obviously, variable names aren't meaningful here. It doesn't accept paths in the filesystem, though. I'm not sure I think that would be a good idea, as it is really mostly finding things in the executable program, not the source code. It also doesn't find constant or exception names, as these currently produce no debug information. Perhaps it is time for me to modify the m3gdb web page, and also see if m3gdb can be built in Windows. Jay wrote: > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full source > paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > -- ------------------------------------------------------------- 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 Wed Feb 13 22:38:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 22:38:04 +0100 Subject: [M3devel] "Microlocation" In-Reply-To: <1202893163.3771.33.camel@faramir.m3w.org> References: <1202893163.3771.33.camel@faramir.m3w.org> Message-ID: <20080213223804.jkey99zegwks8sc4@mail.elegosoft.com> As a first step, I've added p204 to the regression tests in m3tests which contains this program: MODULE Main; IMPORT IO, IP; CONST null = IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {0,0,0,0}}; VAR addr: IP.Address; one := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {1,1,1,1}}; BEGIN addr := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {87,250,125,7}}; addr := null; addr := one; IO.Put("OK\n"); END Main. Initializers null and one work, only the one in the main body leads to code generation errors: "../src/Main.m3", line 1: 4 code generation errors 1 error encountered Any volunteers? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From darko at darko.org Thu Feb 14 01:10:18 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 11:10:18 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B2E62D.1E75.00D7.1@scires.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> Message-ID: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> I actually see some benefit to Jay's postings since they make us examine some of the differences between M3 and C and explain the benefits. These questions might be asked by any C programmer approaching the M3 language. It may be the point that Jay hasn't created and serious software in M3 and needs to be informed of the benefits. I've seen some good responses along these lines from members of the list. But Randy does have a valid point. M3 is is not just different to C, it's the antithesis of C. It's everything C isn't and the language designers went to great lengths to make it this way. It's why most of us use the language. I certainly wouldn't like to drive anyone away because they have a different point of view, but it may be a good idea to examine problems and solutions more closely and offer other solutions that 'why not do it like C'. In the case of printf, it is useful, when debugging especially, and I've created some code which takes a list of refany parameters and prints them out. It is a bit inefficient since any 'atomic' values such as integers need to be allocated but it also prints out all the fields of structures and arrays. But it is completely safe. If there were a need for a more efficient way to generated formatted strings, I'd write something else more efficient but also configurable since embedding fixed strings in your code is generally a a bad idea. On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > Jay: > > I don't want to be offensive, but quite frankly I'm tired of > continually reading your gripes about Modula-3 as a language and > your pining for C. > > This forum is for those people interested in advancing the state of > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > us who are M3 zealots for the most part probably would welcome any > move to divest CM3 of all underpinnings from the C world. > > Have you seriously studied the Modula-3 language and used it to > build production software? I think some of your comments suggest > that you are not a true Modula-3 programmer and that you still cling > to the C-way of doing things rather than embracing the Modula-3 way. > > Now, I do think that most people are interested in improving things > and no language is perfect, so any well-thought-out proposal for a > change to the language is welcome for consideration, But in this > mail list forum, I for one would appreciate less ranting about C and > more constructive Modula-3. > > Truly, I do not want to offend you. Maybe I'm just having a bad > day, but I encourage you to try and focus your posts to the > advancement of Modula-3. > > Regards, > Randy > > >>> Jay 2/12/2008 11:28 PM >>> > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. > > The debugging options seem really poor everywhere and esp. on NT386. > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full > source paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > > Other than printf'ing, I also end up getting a stack in cdb with no > symbols and then disasm in gdb to find what the functions were. That > works fine a few times, but I hope not to do it often. Somewhat > lucky I could even get a stack. Because, see, cdb is nice enough to > stop on access violations by default (such as the time/date code was > causing). gdb has a promising sounding feature, the ability to stop > on "signals", which I think an access violation would count as, oh, > but that feature isn't implemented, sorry. Ok, true, think about it > more and I can break on the toplevel exception handler in > cygwin1.dll, not sure that always works or not, it's an > implementation detail, but heck, when you are debugging, take > advantage of whatever you have. :) > > RTIO, is too verbose for me. > But darnit, I can't really have printf..puts is about the best I > could do.. > Oh, but no, since TEXT != char* even that isn't useful. > fread/fwrite maybe though. > > On a different hand (how many are there? :) ), have you looked in > m3core\src\unix? > There is just tons of dead stuff, stuff with comments about it > perhaps being wrong, "use with care". > It seemed to me maybe the point was to expose "all" of /usr/include. > Someone, other than me, sure seems to have gone overboard, like > someone using Ultrix and Linux 1.x, and then it copied around. > Heck, look at the mem* functions being commented out (and probably > using the incorrect type int) because Ultrix or somesuch didn't have > them. I uncommented them to fix a build. And notice that these > functions, again, like most of printf, are /extremely/ portable in > functionality and exact binary interface (yeah yeah, I've heard of > bcopy and bzero). > > What there was of Cstdio.i3 seemed very possibly wrong, at least on > many targets, and very doubtfully useful for anything, and I think > I've now shown unused. > > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop > rewriting them... > Or some other language, ok...not going to be solved in this forum. > To go the unpopular route (again), MS CLR/.NET among many other > things, attempts to solve this very problem. > One way to describe "interfaces" that "all" languages can > understand...at least for some subset of languages features.. > > Just as tedious btw, it is often more portable to wrap all the C > APIs in C, exposing a portable controled Modula-3 interface > independent of the precise header content. Like errno and my > get_stderr/out/in. > > - Jay > > > > To: hosking at cs.purdue.edu > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > This is also an excellent reason not to permit "interfaces" to C > > code inlined into MODULEs. > > > > Interfaces are the contract that the implementation has to live up > > to. Ok, so it happens that under operating system X on architecture > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > system, which either isn't built in C or where the function doesn't > > exist, it might be convenient to implement the interface in (gasp!) > > Modula-3! > > > > (I use this pattern as follows: on systems where Intel's Fortran > > compiler is available, compile from assembly (which was generated > > by ifort). On other systems, the code is implemented in Modula-3.) > > > > Mika > > > > Tony Hosking writes: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > >What happens when I want to bring up a system where there is no > > >C?!?! Consider the SPIN OS perhaps... > > > > > >Maybe I am just being overly fusty... > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > >> What we _maybe_ can do... is to make some special, preprocessable > > >> source > > >> form, which some quake command can parse into multiple files in > their > > >> folders. And these file can be compiled later...Kind of how > generic > > >> works. > > >> > > >> But, as current system works, and it does it very well, and as > only > > >> case > > >> where we really need this is Windows... most Unices being or > becoming > > >> POSIX... I don't see it's smart to spend resources on becoming > more > > >> C... > > >> Esp when "founding fathers" made it so good and so much non-C :). > > >> > > >> If we really need to make some approach to "their world", it's > much > > >> better to work on interoperability issues and thus cement our > > >> first-class-citizen language status even more. > > >> > > >> dd > > >> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > >>> Jay: > > >>> > > >>> My understanding of Modula-3 is that rather than cluttering up > the > > >>> source code with a bunch of preprocessor directives to deal > with the > > >>> various changes needed by various platforms, a separate source > > >>> file is > > >>> used for platforms whose implementation must diverge. The > m3makefile > > >>> is used to control the selection of these platform sources at > build > > >>> time. I like this approach much better. > > >>> > > >>> Regards, > > >>> Randy > > >>> > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > >>> So I have NOT thought this through. > > >>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good > > >>> idea. > > >>> > > >>> Something like either the ability to prefix pragmas with a > target, or > > >>> an "iftarget" and "ifnottarget" pragma. > > >>> > > >>> Something like so: > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> It's a small can of worms. > > >>> Where can they be placed? Only at "global" scope? (ie: > toplevel in an > > >>> interface/module). > > >>> > > >>> What about IF_OSTYPE? > > >>> What about expressions? > > >>> IF_TARGET NT386 OR NTAMD64 > > >>> > > >>> IF_TARGET STARTS(NT) > > >>> > > >>> etc. > > >>> > > >>> I don't really have enough interest here to work through this, > just > > >>> sending out the bait... > > >>> > > >>> Obviously this was triggered by my happening into the odbc > directory > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > calling > > >>> conventions with a target. > > >>> > > >>> This reminds me of an important point here however -- nobody > else is > > >>> going to make the mistake of ever having multiple calling > > >>> conventions. > > >>> Therefore the generality of prefixing WINAPI with NT386: is > useless. > > >>> Unless Mac68K support is added. > > >>> > > >>> And here is some rationale even. The PC and Mac evolved from > "small" > > >>> systems, where assembly programming was common, more people > knew more > > >>> lower level details and playing games with calling conventions > was > > >>> something anyone could do. Most other current systems are > rooted in C > > >>> programming. Working in C, calling conventions are generally > in a > > >>> hidden layer below what anyone thinks about. Therefore, the > smaller > > >>> number of capable people working at that level have the good > sense to > > >>> only have one calling convention. No more systems will evolve > from > > >>> "small", at least not without having observed this history. > > >>> Therefore, > > >>> there will no longer be multiple calling conventions. > > >>> > > >>> That is my theory at least. > > >>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > __thiscall is > > >>> only x86 > > >> -- > > >> Dragi??a Duri?? > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Thu Feb 14 01:34:44 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 00:34:44 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: I'll try to repeat myself less and ramble less, and stay constructive... I understand that printf type unsafety stinks and I have been bitten by it, but it is nicely terse, crude but effective, I'm going to throw away the code probably once the bug is fixed. (Ok, I like to comment out or somehow disable sometimes maybe but that is a different point, it's still not the height of production code; and yes, I realize it's a slippery slope and the next thing I'll do is use it in production code; debugging is just what I'm doing now, next up, real code). You can't just be the antithesis of C. You have to decide what it is about C that is wrong and fix it or do it over. And then of course, agreement on what is wrong. I probably see less wrong than you. Bad module system -- #include. Bad module system -- preprocesor which kills or damages other efforts at language-aware tools. Beyond this, at the moment, I am unsure. I have "argued for" C++ for further "problems" in C, but I have "grown" (or shrunk? :) ) to appreciate that C might not be as bad as I used to think. If you start over completely from scratch, you should still look at what is out there. Granted, some things are mostly arbitrary. Braces vs. begin/end. But the editors all support braces now. Until you get me to change editors (probably never), Modula-3 is always going to be less convenient. At this point you are just fighting the vast majority (except Python...). It could have gone differently, but C won. If you ignore that lowest level thing, there are places where Modula-3 is perfectly good, but doesn't take the next step. A good example I think here is it has nice "objects", however it requires they be heap allocated I think even in unsafe code. You should be able stack (or global) allocate something with "virtual functions". It seems an arbitrary limitation. I realize in safe code, you have to heap allocate more anyway, but that is a different point I think. Similarly is "multiple inheritance just of interfaces". I realize though..this hides a "vtable per interface". Maybe is much more expensive than people realize and shouldn't be provided lightly. SUBARRAY is probably example where I don't/didn't know the language well enough. And maybe the docs aren't good here. And VAR/BEGIN. Maybe I just need to reread Nelson's book. You know..reference vs. tutorial. The language reference is very very terse and that is ok. Short on examples. A tutorial that gives many examples might be good. Hey maybe I'm just the newbie in a good position to write it. (not) I guess I should be in comp.lang.c.advocacy. :) To a large extent I'm just looking for a small smart group to have a friendly intellectual discussion with. (and of course, don't mess up their code) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay's postings since they make us > examine some of the differences between M3 and C and explain the > benefits. These questions might be asked by any C programmer > approaching the M3 language. It may be the point that Jay hasn't > created and serious software in M3 and needs to be informed of the > benefits. I've seen some good responses along these lines from members > of the list.> > But Randy does have a valid point. M3 is is not just different to C, > it's the antithesis of C. It's everything C isn't and the language > designers went to great lengths to make it this way. It's why most of > us use the language.> > I certainly wouldn't like to drive anyone away because they have a > different point of view, but it may be a good idea to examine problems > and solutions more closely and offer other solutions that 'why not do > it like C'.> > In the case of printf, it is useful, when debugging especially, and > I've created some code which takes a list of refany parameters and > prints them out. It is a bit inefficient since any 'atomic' values > such as integers need to be allocated but it also prints out all the > fields of structures and arrays. But it is completely safe. If there > were a need for a more efficient way to generated formatted strings, > I'd write something else more efficient but also configurable since > embedding fixed strings in your code is generally a a bad idea.> > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be offensive, but quite frankly I'm tired of > > continually reading your gripes about Modula-3 as a language and > > your pining for C.> >> > This forum is for those people interested in advancing the state of > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealots for the most part probably would welcome any > > move to divest CM3 of all underpinnings from the C world.> >> > Have you seriously studied the Modula-3 language and used it to > > build production software? I think some of your comments suggest > > that you are not a true Modula-3 programmer and that you still cling > > to the C-way of doing things rather than embracing the Modula-3 way.> >> > Now, I do think that most people are interested in improving things > > and no language is perfect, so any well-thought-out proposal for a > > change to the language is welcome for consideration, But in this > > mail list forum, I for one would appreciate less ranting about C and > > more constructive Modula-3.> >> > Truly, I do not want to offend you. Maybe I'm just having a bad > > day, but I encourage you to try and focus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy> >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> >> > This is somewhat my point.> > When I am debugging, I really miss printf.> >> > The debugging options seem really poor everywhere and esp. on NT386.> >> > gdb has all wierded out variable names for one thing.> > And I think we should fix it so that that the symbols have full > > source paths.> > I realize they would only be correct on one machine, and hopefully > > there's a decent story for copying the files.> > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot.> >> > Other than printf'ing, I also end up getting a stack in cdb with no > > symbols and then disasm in gdb to find what the functions were. That > > works fine a few times, but I hope not to do it often. Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enough to > > stop on access violations by default (such as the time/date code was > > causing). gdb has a promising sounding feature, the ability to stop > > on "signals", which I think an access violation would count as, oh, > > but that feature isn't implemented, sorry. Ok, true, think about it > > more and I can break on the toplevel exception handler in > > cygwin1.dll, not sure that always works or not, it's an > > implementation detail, but heck, when you are debugging, take > > advantage of whatever you have. :)> >> > RTIO, is too verbose for me.> > But darnit, I can't really have printf..puts is about the best I > > could do..> > Oh, but no, since TEXT != char* even that isn't useful.> > fread/fwrite maybe though.> >> > On a different hand (how many are there? :) ), have you looked in > > m3core\src\unix?> > There is just tons of dead stuff, stuff with comments about it > > perhaps being wrong, "use with care".> > It seemed to me maybe the point was to expose "all" of /usr/include.> > Someone, other than me, sure seems to have gone overboard, like > > someone using Ultrix and Linux 1.x, and then it copied around.> > Heck, look at the mem* functions being commented out (and probably > > using the incorrect type int) because Ultrix or somesuch didn't have > > them. I uncommented them to fix a build. And notice that these > > functions, again, like most of printf, are /extremely/ portable in > > functionality and exact binary interface (yeah yeah, I've heard of > > bcopy and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, at least on > > many targets, and very doubtfully useful for anything, and I think > > I've now shown unused.> >> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> >> > But wrapping everything in Modula-3 is so tedious...> > Oh for all languages to just understand C headers so we can stop > > rewriting them...> > Or some other language, ok...not going to be solved in this forum.> > To go the unpopular route (again), MS CLR/.NET among many other > > things, attempts to solve this very problem.> > One way to describe "interfaces" that "all" languages can > > understand...at least for some subset of languages features..> >> > Just as tedious btw, it is often more portable to wrap all the C > > APIs in C, exposing a portable controled Modula-3 interface > > independent of the precise header content. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: hosking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] "target specific pragmas"?> > >> > >> > > This is also an excellent reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >> > > Interfaces are the contract that the implementation has to live up> > > to. Ok, so it happens that under operating system X on architecture> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> > > system, which either isn't built in C or where the function doesn't> > > exist, it might be convenient to implement the interface in (gasp!)> > > Modula-3!> > >> > > (I use this pattern as follows: on systems where Intel's Fortran> > > compiler is available, compile from assembly (which was generated> > > by ifort). On other systems, the code is implemented in Modula-3.)> > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> > > >What happens when I want to bring up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps...> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> > > >> > > >> What we _maybe_ can do... is to make some special, preprocessable> > > >> source> > > >> form, which some quake command can parse into multiple files in > > their> > > >> folders. And these file can be compiled later...Kind of how > > generic> > > >> works.> > > >>> > > >> But, as current system works, and it does it very well, and as > > only> > > >> case> > > >> where we really need this is Windows... most Unices being or > > becoming> > > >> POSIX... I don't see it's smart to spend resources on becoming > > more> > > >> C...> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > > >>> > > >> If we really need to make some approach to "their world", it's > > much> > > >> better to work on interoperability issues and thus cement our> > > >> first-class-citizen language status even more.> > > >>> > > >> dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rather than cluttering up > > the> > > >>> source code with a bunch of preprocessor directives to deal > > with the> > > >>> various changes needed by various platforms, a separate source> > > >>> file is> > > >>> used for platforms whose implementation must diverge. The > > m3makefile> > > >>> is used to control the selection of these platform sources at > > build> > > >>> time. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> Randy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> > > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>> > > >>> Something like either the ability to prefix pragmas with a > > target, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>> Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interface/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about expressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET STARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enough interest here to work through this, > > just> > > >>> sending out the bait...> > > >>>> > > >>> Obviously this was triggered by my happening into the odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > > >>> This reminds me of an important point here however -- nobody > > else is> > > >>> going to make the mistake of ever having multiple calling> > > >>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> > > >>> And here is some rationale even. The PC and Mac evolved from > > "small"> > > >>> systems, where assembly programming was common, more people > > knew more> > > >>> lower level details and playing games with calling conventions > > was> > > >>> something anyone could do. Most other current systems are > > rooted in C> > > >>> programming. Working in C, calling conventions are generally > > in a> > > >>> hidden layer below what anyone thinks about. Therefore, the > > smaller> > > >>> number of capable people working at that level have the good > > sense to> > > >>> only have one calling convention. No more systems will evolve > > from> > > >>> "small", at least not without having observed this history.> > > >>> Therefore,> > > >>> there will no longer be multiple calling conventions.> > > >>>> > > >>> That is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> Dragi??a Duri?? > >> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Thu Feb 14 02:09:40 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 12:09:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> M3 is the antithesis in the sense that it takes the opposite approach. C has few protections, M3 has many. M3 does examine what was wrong with C and other languages and fix them and it did a good job. The M3 design team made an explicit goal to look at features from other languages and take the best. The fact that M3 works so well is the proof. Some of the things you raise, like braces or stack allocations of objects are just features of C++ with no justification. Can you show that typing less characters is important? You say M3 is less convenient, but what is less convenient, less typing or less bugs? Do you spend most of your time typing or thinking when you write code? Should language include every feature anyone can think of? How is excluding unimportant features 'arbitrary'? Each feature must be weighed to avoid unnecessary complexity and size, which have a direct impact on compiler maintainability and language usability. Language bloat is a real problem. I doubt that anyone understands the full semantics of C++. You say that C has 'won', but in what sense? More people use it? Language design is not American Idol, it's not a question of who has the most votes. You have to do more than list features of C or C++ and your opinions on them. You have to provide some rationale as to their benefit which convinces people. On 14/02/2008, at 11:34 AM, Jay wrote: > I'll try to repeat myself less and ramble less, and stay > constructive... > > I understand that printf type unsafety stinks and I have been bitten > by it, but it is nicely terse, crude but effective, I'm going to > throw away the code probably once the bug is fixed. (Ok, I like to > comment out or somehow disable sometimes maybe but that is a > different point, it's still not the height of production code; and > yes, I realize it's a slippery slope and the next thing I'll do is > use it in production code; debugging is just what I'm doing now, > next up, real code). > > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. > > If you start over completely from scratch, you should still look at > what is out there. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. > > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. > > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. > > SUBARRAY is probably example where I don't/didn't know the language > well enough. > And maybe the docs aren't good here. > And VAR/BEGIN. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) > > I guess I should be in comp.lang.c.advocacy. :) > > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) > > - Jay > > > > > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > > From: darko at darko.org > > To: rcoleburn at scires.com > > Subject: Re: [M3devel] "target specific pragmas"? > > Date: Thu, 14 Feb 2008 11:10:18 +1100 > > > > I actually see some benefit to Jay's postings since they make us > > examine some of the differences between M3 and C and explain the > > benefits. These questions might be asked by any C programmer > > approaching the M3 language. It may be the point that Jay hasn't > > created and serious software in M3 and needs to be informed of the > > benefits. I've seen some good responses along these lines from > members > > of the list. > > > > But Randy does have a valid point. M3 is is not just different to C, > > it's the antithesis of C. It's everything C isn't and the language > > designers went to great lengths to make it this way. It's why most > of > > us use the language. > > > > I certainly wouldn't like to drive anyone away because they have a > > different point of view, but it may be a good idea to examine > problems > > and solutions more closely and offer other solutions that 'why not > do > > it like C'. > > > > In the case of printf, it is useful, when debugging especially, and > > I've created some code which takes a list of refany parameters and > > prints them out. It is a bit inefficient since any 'atomic' values > > such as integers need to be allocated but it also prints out all the > > fields of structures and arrays. But it is completely safe. If there > > were a need for a more efficient way to generated formatted strings, > > I'd write something else more efficient but also configurable since > > embedding fixed strings in your code is generally a a bad idea. > > > > > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > > > > > Jay: > > > > > > I don't want to be offensive, but quite frankly I'm tired of > > > continually reading your gripes about Modula-3 as a language and > > > your pining for C. > > > > > > This forum is for those people interested in advancing the state > of > > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > > us who are M3 zealots for the most part probably would welcome any > > > move to divest CM3 of all underpinnings from the C world. > > > > > > Have you seriously studied the Modula-3 language and used it to > > > build production software? I think some of your comments suggest > > > that you are not a true Modula-3 programmer and that you still > cling > > > to the C-way of doing things rather than embracing the Modula-3 > way. > > > > > > Now, I do think that most people are interested in improving > things > > > and no language is perfect, so any well-thought-out proposal for a > > > change to the language is welcome for consideration, But in this > > > mail list forum, I for one would appreciate less ranting about C > and > > > more constructive Modula-3. > > > > > > Truly, I do not want to offend you. Maybe I'm just having a bad > > > day, but I encourage you to try and focus your posts to the > > > advancement of Modula-3. > > > > > > Regards, > > > Randy > > > > > > >>> Jay 2/12/2008 11:28 PM >>> > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > > > This is somewhat my point. > > > When I am debugging, I really miss printf. > > > > > > The debugging options seem really poor everywhere and esp. on > NT386. > > > > > > gdb has all wierded out variable names for one thing. > > > And I think we should fix it so that that the symbols have full > > > source paths. > > > I realize they would only be correct on one machine, and hopefully > > > there's a decent story for copying the files. > > > Yeah, I know about "dir" but haven't yet formed a .gdbinit or > whatnot. > > > > > > Other than printf'ing, I also end up getting a stack in cdb with > no > > > symbols and then disasm in gdb to find what the functions were. > That > > > works fine a few times, but I hope not to do it often. Somewhat > > > lucky I could even get a stack. Because, see, cdb is nice enough > to > > > stop on access violations by default (such as the time/date code > was > > > causing). gdb has a promising sounding feature, the ability to > stop > > > on "signals", which I think an access violation would count as, > oh, > > > but that feature isn't implemented, sorry. Ok, true, think about > it > > > more and I can break on the toplevel exception handler in > > > cygwin1.dll, not sure that always works or not, it's an > > > implementation detail, but heck, when you are debugging, take > > > advantage of whatever you have. :) > > > > > > RTIO, is too verbose for me. > > > But darnit, I can't really have printf..puts is about the best I > > > could do.. > > > Oh, but no, since TEXT != char* even that isn't useful. > > > fread/fwrite maybe though. > > > > > > On a different hand (how many are there? :) ), have you looked in > > > m3core\src\unix? > > > There is just tons of dead stuff, stuff with comments about it > > > perhaps being wrong, "use with care". > > > It seemed to me maybe the point was to expose "all" of /usr/ > include. > > > Someone, other than me, sure seems to have gone overboard, like > > > someone using Ultrix and Linux 1.x, and then it copied around. > > > Heck, look at the mem* functions being commented out (and probably > > > using the incorrect type int) because Ultrix or somesuch didn't > have > > > them. I uncommented them to fix a build. And notice that these > > > functions, again, like most of printf, are /extremely/ portable in > > > functionality and exact binary interface (yeah yeah, I've heard of > > > bcopy and bzero). > > > > > > What there was of Cstdio.i3 seemed very possibly wrong, at least > on > > > many targets, and very doubtfully useful for anything, and I think > > > I've now shown unused. > > > > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > > > But wrapping everything in Modula-3 is so tedious... > > > Oh for all languages to just understand C headers so we can stop > > > rewriting them... > > > Or some other language, ok...not going to be solved in this forum. > > > To go the unpopular route (again), MS CLR/.NET among many other > > > things, attempts to solve this very problem. > > > One way to describe "interfaces" that "all" languages can > > > understand...at least for some subset of languages features.. > > > > > > Just as tedious btw, it is often more portable to wrap all the C > > > APIs in C, exposing a portable controled Modula-3 interface > > > independent of the precise header content. Like errno and my > > > get_stderr/out/in. > > > > > > - Jay > > > > > > > > > > To: hosking at cs.purdue.edu > > > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > > > From: mika at async.caltech.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > > > > > > > This is also an excellent reason not to permit "interfaces" to C > > > > code inlined into MODULEs. > > > > > > > > Interfaces are the contract that the implementation has to > live up > > > > to. Ok, so it happens that under operating system X on > architecture > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > system, which either isn't built in C or where the function > doesn't > > > > exist, it might be convenient to implement the interface in > (gasp!) > > > > Modula-3! > > > > > > > > (I use this pattern as follows: on systems where Intel's Fortran > > > > compiler is available, compile from assembly (which was > generated > > > > by ifort). On other systems, the code is implemented in > Modula-3.) > > > > > > > > Mika > > > > > > > > Tony Hosking writes: > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > >What happens when I want to bring up a system where there is no > > > > >C?!?! Consider the SPIN OS perhaps... > > > > > > > > > >Maybe I am just being overly fusty... > > > > > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > > > > > >> What we _maybe_ can do... is to make some special, > preprocessable > > > > >> source > > > > >> form, which some quake command can parse into multiple > files in > > > their > > > > >> folders. And these file can be compiled later...Kind of how > > > generic > > > > >> works. > > > > >> > > > > >> But, as current system works, and it does it very well, and > as > > > only > > > > >> case > > > > >> where we really need this is Windows... most Unices being or > > > becoming > > > > >> POSIX... I don't see it's smart to spend resources on > becoming > > > more > > > > >> C... > > > > >> Esp when "founding fathers" made it so good and so much non- > C :). > > > > >> > > > > >> If we really need to make some approach to "their world", > it's > > > much > > > > >> better to work on interoperability issues and thus cement our > > > > >> first-class-citizen language status even more. > > > > >> > > > > >> dd > > > > >> > > > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > > > >>> Jay: > > > > >>> > > > > >>> My understanding of Modula-3 is that rather than > cluttering up > > > the > > > > >>> source code with a bunch of preprocessor directives to deal > > > with the > > > > >>> various changes needed by various platforms, a separate > source > > > > >>> file is > > > > >>> used for platforms whose implementation must diverge. The > > > m3makefile > > > > >>> is used to control the selection of these platform sources > at > > > build > > > > >>> time. I like this approach much better. > > > > >>> > > > > >>> Regards, > > > > >>> Randy > > > > >>> > > > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > > > >>> So I have NOT thought this through. > > > > >>> > > > > >>> I wonder if "preprocessing" dependent only on "target" is > a good > > > > >>> idea. > > > > >>> > > > > >>> Something like either the ability to prefix pragmas with a > > > target, or > > > > >>> an "iftarget" and "ifnottarget" pragma. > > > > >>> > > > > >>> Something like so: > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> It's a small can of worms. > > > > >>> Where can they be placed? Only at "global" scope? (ie: > > > toplevel in an > > > > >>> interface/module). > > > > >>> > > > > >>> What about IF_OSTYPE? > > > > >>> What about expressions? > > > > >>> IF_TARGET NT386 OR NTAMD64 > > > > >>> > > > > >>> IF_TARGET STARTS(NT) > > > > >>> > > > > >>> etc. > > > > >>> > > > > >>> I don't really have enough interest here to work through > this, > > > just > > > > >>> sending out the bait... > > > > >>> > > > > >>> Obviously this was triggered by my happening into the odbc > > > directory > > > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > > calling > > > > >>> conventions with a target. > > > > >>> > > > > >>> This reminds me of an important point here however -- nobody > > > else is > > > > >>> going to make the mistake of ever having multiple calling > > > > >>> conventions. > > > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > > useless. > > > > >>> Unless Mac68K support is added. > > > > >>> > > > > >>> And here is some rationale even. The PC and Mac evolved from > > > "small" > > > > >>> systems, where assembly programming was common, more people > > > knew more > > > > >>> lower level details and playing games with calling > conventions > > > was > > > > >>> something anyone could do. Most other current systems are > > > rooted in C > > > > >>> programming. Working in C, calling conventions are generally > > > in a > > > > >>> hidden layer below what anyone thinks about. Therefore, the > > > smaller > > > > >>> number of capable people working at that level have the good > > > sense to > > > > >>> only have one calling convention. No more systems will > evolve > > > from > > > > >>> "small", at least not without having observed this history. > > > > >>> Therefore, > > > > >>> there will no longer be multiple calling conventions. > > > > >>> > > > > >>> That is my theory at least. > > > > >>> > > > > >>> Oh, Windows does also have __thiscall and __clrcall. > > > __thiscall is > > > > >>> only x86 > > > > >> -- > > > > >> Dragi??a Duri?? > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From mika at async.caltech.edu Thu Feb 14 02:43:13 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 17:43:13 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. A few things I know I like about M3, and don't exist in the C languages, are: * enumerated types that work well * integer subranges * arrays(!!) * arrays indexed by enumerations and subranges * absence of name mangling problems (I'm willing to accept Quake in return) * the ability to add code/declarations/types to ANY interface and not have it break a program. NO OTHER LANGUAGE (that I've heard of) HAS THIS PROPERTY. * a lot of other Java-ish properties, without being Java. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. Yes it's a lot easier to code M3 in emacs... modula3.el is a wonderful little thing to have. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. Not even C++ has virtual methods in stack-allocated objects does it? If there's a language that has a lot of arbitrary limitations in this area it's C++. It's kind of funny: if you know Modula-3, you start by wondering how C++ implements X, where X is a feature you would like but M3 lacks, and then you find that while C++ does indeed implement X', that is, X in a restricted sense, it does actually not implement X in the full generality you'd like. And for the same reasons that M3 doesn't touch it in the first place. Stack-allocated objects are an example of this. If you want stack-allocated data structures, use a RECORD and a PROCEDURE. That will give you almost exactly the same thing that a stack-allocated object gives you in C++! >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) Try Harbison's book? Or read a lot of the SRC code. Some of it is quite beautiful. About C++: do you *really* know C++? I was reading Stroustrup's book a while back and after reading four or five times "if you want to try this, ask an experienced colleague first" I gave up in disgust on trying to understand C++. There are so many odd little ways you can go wrong in C++. Sometimes assigning an object to a variable causes your program to break in mysterious and horrible ways, sometimes... C++ programmers also tend to underestimate how effective garbage collection is in simplifying things. This is different from saying "garbage collection helps you avoid memory management errors" (because you say "I am a competent C++ programmer, I never make memory management errors"). Garbage collection lets you structure your code in ways that simply is not possible if you have to worry about which part of it is going to allocate and which part is going to deallocate memory. The last and probably biggest advantage of M3 over C++ is that you can look at a program and immediately know what it means. And also know that it *can't* mean anything else. The programmer couldn't, even if he was maximally sadistic, have overloaded equals to mean not-equals, right shift to mean left shift, and left shift to mean increment. C++ lets you do this, and there are a large number of programmers out there who seemingly take advantage of every language feature they can get their hands on that lets them obscure their programs. I would summarize it as follows. Modula-3 and C++ let you compile almost exactly the same machine code. Apart from that, Modula-3 does it in a way that lets you write safe programs, and C++ does it in a way that lets you write obscure programs. Something that has become increasingly clear to me is that Modula-3 and C++ live in something of a desert. There are very few modern programming languages that are as "close to the machine" as these two. All the work that people do today (that gets any attention) is in things like Java (which is incredibly complicated, have you ever tried to compile HotSpot?) and Python (which is all right but incredibly inefficient). The more academic languages like ML and things like Self... well I won't even say anything about those. If you want a safe language that works with traditional compiler tools, Modula-3 is just about the only one out there. Finally, there is something about Randy's comment that's very true. Modula-3 is a "dead language". People that "still" use it are going to be fanatics about why they use it, rather than C or C++. If you are asked what programming language you use for development, and you answer "Modula-3" people will almost always look at you like you're crazy. We do indeed use it because it is very different from C and C++, or else we would have saved ourselves a LOT of trouble (I forget just how many existing C and C++ libraries and tools I have reimplemented just so I could stay in Modula-3) by just going with the crowd. Mika >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From mika at async.caltech.edu Thu Feb 14 03:00:46 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 18:00:46 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> I should point out that I am not trying to tell you that Modula-3 is better than C++ and you should immediately switch and stop talking about the wonderful features of C++. It's not and if you are competent enough to be coding in C++ and happy with it you should certainly not. A way to summarize what I said before is this. I do not consider myself a good programmer. Yet I sit in front of my computer trying to write software that plays with millions of dollars of other people's money. I simply do not trust myself to use a tool as sharp and unconstrained as C++. The constraints of enumerated types, subranges, typechecking at interfaces and runtime, bounds-checked arrays etc., let me sleep a bit better (but still not well). I am reminded of something my advisor's advisor once wrote, regarding the difficulty of producing large software systems: We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers. ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF CACM 15, 1972, #10, 859-866) Mika Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From wagner at elegosoft.com Thu Feb 14 09:12:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 14 Feb 2008 09:12:09 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Quoting Jay : > I'll try to repeat myself less and ramble less, and stay constructive... That would be great. It's really nice that there is much more discussion here since you joined and much more work on the Windows targets, but it would still even better if you could (a) be less sarcastic (which tends to annoy some others) and (b) think once again before hitting the send button. On some days there's even so much traffic here that I can only browse the headers (there are dozens of other mails I need to pay close attention to). > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. C is good for special kinds of system programming, with very experienced users and a code base that can still be controlled by a few minds. Large projects tend to stretch these bounds easily. For large projects taking place in a commercial environment with many teams and well-specified layers and interfaces, M3 is IMO much better suited than C (or C++, or even Java), though ironically it's not really used there (which is a pity). > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. I like C much better than C++; it's small and can be useful. C++ is way too large and complex and has never been exactly defined. When we used to program point of sale systems in the early 90s for a company here in Berlin, we had two large files of more than 1200 pages which was the upcoming C++ spec draft. Nobody has ever read even 1/10 of it. We tried about half a dozen compilers, each with nice features, but they were completely incompatible, and cost much efforts to keep code even syntactically accepted. > If you start over completely from scratch, you should still look at > what is out there. Well, we're not doing that here (starting from scratch). M3 is a well-defined and well working language, and the community here likes to use it. I'm not against language changes in general, but they need to be considered very well if we really want to improve the language. Addition of a portable 64 bit integer type for once was something that was needed, because hardware architectures and operating systems have changed. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. Any decent editor can be configured wrt. syntax highlighting and writing support (we even had that for the simple DOS editors we were using at the university together with Modula-2). Have you tried (X)Emacs? There's a really nice m3-mode for it, with highlighting and automatic completion of all language constructs. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. I'm not fighting anybody here ;-) > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. I'm not sure if that is really needed. > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. Multiple inheritance was left out of the language after long discussions because it was not really understood at that time. It may be that things have changed in this respect, but I still don't think it is. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) You can express quite a lot of unexpected things with the few language constructs. Often I'm still amazed at the ideas of other programmers when reading M3 code. > I guess I should be in comp.lang.c.advocacy. :) Yes, some of your comments would be better placed there :) > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) I think you can have that here. People are willing to discuss and think things over, but the pace may be somewhat slower than you'd like :-) (It's not as bad as with Tolkien's Ents, but still ... slow :) So, as others have noted, it's great that there is so much activity recently, but it would still be better if the discussions and comments were more focused on important language related content about M3. Nobody has accused you of malicious intentions, and you've always accepted objections and corrections by others as far as I remember. I think what is mostly needed is to slightly adapt your style of working and discussing things to become better accepted here. Don't speak out too rash, and don't commit lots of small changes too soon. Work things out and become more self-confident about the results of your work. I'm sure you can contribute many interesting things to M3. Olaf PS: Sorry if some of the above reads as if I'm your teacher ;-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 14 09:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 08:38:14 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> References: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." <200802140200.m1E20k5k062986@camembert.async.caltech.edu> Message-ID: too much to respond to right now... Yes C++ certainly allows virtual functions on stack allocated objects. class Foo{public: virtual void Bar();}; void F(){ Foo foo; foo.Bar();} works fine. You can take the address and pass it around, etc., just don't return it of course. You are right that a record with procedures might suffice.I've been using them in C lately: struct Foo_t;typedef struct Foo_t Foo_t;struct FooFunctions_t;typedef struct FooFunctions_t FooFunctions_t; struct FooFunctions_t{ // probably never any data here, it muddies the model, but maybe void (*DoSomething)(Foo_t*); void (*OrSomethingElse)(Foo_t*, size_t a, size_t b);}; struct Foo_t{ // probably never any data here, it muddies the model, but maybe const FooFunctions_t* Functions;}; // see winnt.h for exactly correct definition#define CONTAINING_RECORD(basepointer, derivedtype, basefield) ((derivedtype*) ((char*)basepointer) - (offsetof(derivedtype, basefield)))) struct Bar_t{ size_t BarData...; Foo_t Base;}; void Bar_DoSomething(Foo_t* Foo){ Bar* = CONTAINING_RECORD(Foo, Bar_t, Base) do something with Bar->BarData...} void Bar_OrSomethingElse(...) ... const FooFunctions ={ &Bar_DoSomething, &Bar_OrSomethingElse}; Foo_t* Bar_Create(){ Bar_t* Bar = (Bar_t*) calloc(1, sizeof(*Bar)); if (Bar == NULL) .... Bar->Functions = &FooFunctions; return &Bar->Base; } Foo_t* f = Bar_Create(); f->Functions->DoSomething(f); // ouch a double pointer deref, maybe code will cache the functions though CONTAINING_RECORD isn't really needed here -- Base can be at the start -- but this slightly generalized pattern supports more types of inheritance better. Presumably I can just clone this in about as much Modula-3. I'll have to try it out when I find an excuse for having "COM-like" interfaces. "I can have my C and a good module system too." :) It is a little tedious, but it keeps you off the slippery slope of C++. :) C++ has few stupid limits I can think of. One is that types (or constants) with internal linkage can't be template parameters. void F() { struct point { int a,b; }; std::vector points; // error special_debugging_class<"print me"> abc; // error } Maybe the last is fixed though. And they are both widely acknowledged to be dumb. Though I think they have an obvious rationale. (You all can guess?) True I haven't written much Modula-3. I do look around the tree some and I do see a lot gross duplication of code/effort. Yes Modula-3 enums and sets and their interaction with arrays is nice. It was actually cryptically terse to me at first but I figured it out. Optional bounds checking on arrays, good. C++ gives you what you generally need to implement sets and good arrays. C is soso. You know, the main thing you have to give up in C regarding user defined types is using those special operator characters on them. You must make explicit function calls. There is this real tension between building stuff into a language vs. building in enough facilities for people to put in libraries what they "thought" should be in the language. Same thing even goes for libraries themselves. Do you put more functionality "in" them, or provide the right composable pieces for people to build what they want. Exceptions (which nobody mentioned) are a mixed bag btw. It's not that hard really to get C correct, esp. with macros and goto (seriously!) but also not clearly worth it. Optional garbage collection maybe nice, again not so hard in C, and C++ gives you, in a sense, garbage collection and much much more along these lines via "RIAA". Also true that lots of languages don't compile to native code. The CLR does promise to be the last system to need this (at runtime or install time) and everyone else can target it. Java (VM) is similar but not general purpose enough. True that name mangling is kind of lame. Try searching for the functions, or debugging (how do I specify the name to a command line debugger? It isn't necessarily impossible, but it's another varying complexity.) Also, on the "American Idol" point, true, good point, being right and good is better than being popular, but there are network affects and some of them are desirable. It's true you don't want everyone jumping on your bandwagon, you want to keep some folks out, but having other people writing tools (editors, etc.) that you can use CAN be very nice. True again I'm a lazy typist but a frequent reader. But begin/end are no more readable than braces. It seems arbitrary, except for the network affects that make my editor favor braces. ..Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Wed, 13 Feb 2008 18:00:46 -0800> From: mika at async.caltech.edu> > > I should point out that I am not trying to tell you that Modula-3> is better than C++ and you should immediately switch and stop talking> about the wonderful features of C++. It's not and if you are> competent enough to be coding in C++ and happy with it you should> certainly not.> > A way to summarize what I said before is this. I do not consider> myself a good programmer. Yet I sit in front of my computer trying> to write software that plays with millions of dollars of other> people's money. I simply do not trust myself to use a tool as sharp> and unconstrained as C++. The constraints of enumerated types,> subranges, typechecking at interfaces and runtime, bounds-checked> arrays etc., let me sleep a bit better (but still not well).> > I am reminded of something my advisor's advisor once wrote, regarding> the difficulty of producing large software systems:> > We shall do a much better programming job, provided that we> approach the task with a full appreciation of its tremendous> difficulty, provided that we stick to modest and elegant programming> languages, provided that we respect the intrinsic limitations> of the human mind and approach the task as Very Humble Programmers.> > ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF > CACM 15, 1972, #10, 859-866)> > Mika> > > > > > > Jay writes:> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I'll try to repeat myself less and ramble less, and stay constructive...> >=20> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).> >=20> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.> >Bad module system -- #include.> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.> >Beyond this, at the moment, I am unsure.> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.> >=20> >If you start over completely from scratch, you should still look at what is=> > out there.> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.> >=20> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.> >=20> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.> >=20> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.> > And maybe the docs aren't good here.> >And VAR/BEGIN.> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)> >=20> >I guess I should be in comp.lang.c.advocacy. :)> >=20> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.> >(and of course, don't mess up their code)> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To=> >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> => >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay=> >'s postings since they make us > examine some of the differences between M3=> > and C and explain the > benefits. These questions might be asked by any C => >programmer > approaching the M3 language. It may be the point that Jay hasn=> >'t > created and serious software in M3 and needs to be informed of the > b=> >enefits. I've seen some good responses along these lines from members > of => >the list.> > But Randy does have a valid point. M3 is is not just different=> > to C, > it's the antithesis of C. It's everything C isn't and the language=> > > designers went to great lengths to make it this way. It's why most of > => >us use the language.> > I certainly wouldn't like to drive anyone away beca=> >use they have a > different point of view, but it may be a good idea to exa=> >mine problems > and solutions more closely and offer other solutions that '=> >why not do > it like C'.> > In the case of printf, it is useful, when debug=> >ging especially, and > I've created some code which takes a list of refany => >parameters and > prints them out. It is a bit inefficient since any 'atomic=> >' values > such as integers need to be allocated but it also prints out all=> > the > fields of structures and arrays. But it is completely safe. If there=> > > were a need for a more efficient way to generated formatted strings, > I=> >'d write something else more efficient but also configurable since > embedd=> >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200=> >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off=> >ensive, but quite frankly I'm tired of > > continually reading your gripes => >about Modula-3 as a language and > > your pining for C.> >> > This forum is=> > for those people interested in advancing the state of > > Modula-3. We don=> >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot=> >s for the most part probably would welcome any > > move to divest CM3 of al=> >l underpinnings from the C world.> >> > Have you seriously studied the Modu=> >la-3 language and used it to > > build production software? I think some of=> > your comments suggest > > that you are not a true Modula-3 programmer and => >that you still cling > > to the C-way of doing things rather than embracing=> > the Modula-3 way.> >> > Now, I do think that most people are interested in=> > improving things > > and no language is perfect, so any well-thought-out p=> >roposal for a > > change to the language is welcome for consideration, But => >in this > > mail list forum, I for one would appreciate less ranting about => >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend => >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo=> >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>=> > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip=> >le concern is that once we provide C APIs then C will> > > >permeate the M3=> > space more pervasively (both apps and libraries).> >> > This is somewhat m=> >y point.> > When I am debugging, I really miss printf.> >> > The debugging => >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi=> >erded out variable names for one thing.> > And I think we should fix it so => >that that the symbols have full > > source paths.> > I realize they would o=> >nly be correct on one machine, and hopefully > > there's a decent story for=> > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g=> >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta=> >ck in cdb with no > > symbols and then disasm in gdb to find what the funct=> >ions were. That > > works fine a few times, but I hope not to do it often. => >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou=> >gh to > > stop on access violations by default (such as the time/date code => >was > > causing). gdb has a promising sounding feature, the ability to stop=> > > > on "signals", which I think an access violation would count as, oh, > => >> but that feature isn't implemented, sorry. Ok, true, think about it > > m=> >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n=> >ot sure that always works or not, it's an > > implementation detail, but he=> >ck, when you are debugging, take > > advantage of whatever you have. :)> >>=> > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..=> >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char=> >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen=> >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> => >> There is just tons of dead stuff, stuff with comments about it > > perhap=> >s being wrong, "use with care".> > It seemed to me maybe the point was to e=> >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have => >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co=> >pied around.> > Heck, look at the mem* functions being commented out (and p=> >robably > > using the incorrect type int) because Ultrix or somesuch didn't=> > have > > them. I uncommented them to fix a build. And notice that these > => >> functions, again, like most of printf, are /extremely/ portable in > > fu=> >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy => >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a=> >t least on > > many targets, and very doubtfully useful for anything, and I=> > think > > I've now shown unused.> >> > > Y, the easiest way to implement t=> >he interface is to call a C > > function> > > that "just happens" to have t=> >he correct interface. But on another> >> > But wrapping everything in Modul=> >a-3 is so tedious...> > Oh for all languages to just understand C headers s=> >o we can stop > > rewriting them...> > Or some other language, ok...not goi=> >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR=> >/.NET among many other > > things, attempts to solve this very problem.> > => >One way to describe "interfaces" that "all" languages can > > understand...=> >at least for some subset of languages features..> >> > Just as tedious btw,=> > it is often more portable to wrap all the C > > APIs in C, exposing a port=> >able controled Modula-3 interface > > independent of the precise header con=> >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h=> >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: => >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3=> >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent => >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >=> >> > > Interfaces are the contract that the implementation has to live up> >=> > > to. Ok, so it happens that under operating system X on architecture> > >=> > Y, the easiest way to implement the interface is to call a C > > function>=> > > > that "just happens" to have the correct interface. But on another> > >=> > system, which either isn't built in C or where the function doesn't> > > e=> >xist, it might be convenient to implement the interface in (gasp!)> > > Mod=> >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F=> >ortran> > > compiler is available, compile from assembly (which was generat=> >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>=> > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is=> > that once we provide C APIs then C will> > > >permeate the M3 space more p=> >ervasively (both apps and libraries).> > > >What happens when I want to bri=> >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..=> >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12=> >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma=> >ybe_ can do... is to make some special, preprocessable> > > >> source> > > => >>> form, which some quake command can parse into multiple files in > > thei=> >r> > > >> folders. And these file can be compiled later...Kind of how > > g=> >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it => >does it very well, and as > > only> > > >> case> > > >> where we really nee=> >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d=> >on't see it's smart to spend resources on becoming > > more> > > >> C...> >=> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > => >> >>> > > >> If we really need to make some approach to "their world", it's=> > > > much> > > >> better to work on interoperability issues and thus cement=> > our> > > >> first-class-citizen language status even more.> > > >>> > > >>=> > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote=> >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath=> >er than cluttering up > > the> > > >>> source code with a bunch of preproce=> >ssor directives to deal > > with the> > > >>> various changes needed by var=> >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo=> >rms whose implementation must diverge. The > > m3makefile> > > >>> is used => >to control the selection of these platform sources at > > build> > > >>> ti=> >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R=> >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> => >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "=> >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>=> >> > > >>> Something like either the ability to prefix pragmas with a > > ta=> >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>=> > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END=> >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E=> >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they => >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa=> >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp=> >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S=> >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou=> >gh interest here to work through this, > > just> > > >>> sending out the ba=> >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t=> >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386=> > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >=> > >>> This reminds me of an important point here however -- nobody > > else => >is> > > >>> going to make the mistake of ever having multiple calling> > > => >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with=> > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> => >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s=> >mall"> > > >>> systems, where assembly programming was common, more people => >> > knew more> > > >>> lower level details and playing games with calling c=> >onventions > > was> > > >>> something anyone could do. Most other current s=> >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv=> >entions are generally > > in a> > > >>> hidden layer below what anyone thin=> >ks about. Therefore, the > > smaller> > > >>> number of capable people work=> >ing at that level have the good > > sense to> > > >>> only have one calling=> > convention. No more systems will evolve > > from> > > >>> "small", at leas=> >t not without having observed this history.> > > >>> Therefore,> > > >>> th=> >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That => >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc=> >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D=> >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w=> >ays with Windows Live. Get it now!>=20> >_________________________________________________________________> >Shed those extra pounds with MSN and The Biggest Loser!> >http://biggestloser.msn.com/=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I'll try to repeat myself less and rambl=> >e less, and stay constructive...
> > 
> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).
> > 
> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.
> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.
> >Bad module system -- #include.
> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.
> >Beyond this, at the moment, I am unsure.
> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<=> >BR>> > 
> >If you start over completely from scratch, you should still look at what is=> > out there.
> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.
> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.
> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.
> > 
> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.
> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.
> > 
> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.
> > 
> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.
> >  And maybe the docs aren't good here.
> >And VAR/BEGIN.
> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)
> > 
> >I guess I should be in comp.lang.c.advocacy. :)
> > 
> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.
> >(and of course, don't mess up their code)
> > 
> > - Jay


> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar=> >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar=> >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>=> >;
> I actually see some benefit to Jay's postings since they make us=> >
> examine some of the differences between M3 and C and explain the => >
> benefits. These questions might be asked by any C programmer
&=> >gt; approaching the M3 language. It may be the point that Jay hasn't
&g=> >t; created and serious software in M3 and needs to be informed of the
&=> >gt; benefits. I've seen some good responses along these lines from members => >
> of the list.
>
> But Randy does have a valid point. M=> >3 is is not just different to C,
> it's the antithesis of C. It's ev=> >erything C isn't and the language
> designers went to great lengths => >to make it this way. It's why most of
> us use the language.
>=> >
> I certainly wouldn't like to drive anyone away because they have => >a
> different point of view, but it may be a good idea to examine pr=> >oblems
> and solutions more closely and offer other solutions that '=> >why not do
> it like C'.
>
> In the case of printf, it => >is useful, when debugging especially, and
> I've created some code w=> >hich takes a list of refany parameters and
> prints them out. It is => >a bit inefficient since any 'atomic' values
> such as integers need => >to be allocated but it also prints out all the
> fields of structure=> >s and arrays. But it is completely safe. If there
> were a need for => >a more efficient way to generated formatted strings,
> I'd write som=> >ething else more efficient but also configurable since
> embedding f=> >ixed strings in your code is generally a a bad idea.
>
>
&=> >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > => >Jay:
> >
> > I don't want to be offensive, but quite fran=> >kly I'm tired of
> > continually reading your gripes about Modula=> >-3 as a language and
> > your pining for C.
> >
> => >> This forum is for those people interested in advancing the state of >R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those=> > of
> > us who are M3 zealots for the most part probably would we=> >lcome any
> > move to divest CM3 of all underpinnings from the C => >world.
> >
> > Have you seriously studied the Modula-3 la=> >nguage and used it to
> > build production software? I think some=> > of your comments suggest
> > that you are not a true Modula-3 pr=> >ogrammer and that you still cling
> > to the C-way of doing thing=> >s rather than embracing the Modula-3 way.
> >
> > Now, I => >do think that most people are interested in improving things
> > => >and no language is perfect, so any well-thought-out proposal for a
>=> > > change to the language is welcome for consideration, But in this
=> >> > mail list forum, I for one would appreciate less ranting about C => >and
> > more constructive Modula-3.
> >
> > Tru=> >ly, I do not want to offend you. Maybe I'm just having a bad
> > => >day, but I encourage you to try and focus your posts to the
> > a=> >dvancement of Modula-3.
> >
> > Regards,
> > Ran=> >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2=> >/12/2008 11:28 PM >>>
> > > >My principle concern i=> >s that once we provide C APIs then C will
> > > >permeate th=> >e M3 space more pervasively (both apps and libraries).
> >
>=> > > This is somewhat my point.
> > When I am debugging, I really=> > miss printf.
> >
> > The debugging options seem really p=> >oor everywhere and esp. on NT386.
> >
> > gdb has all wie=> >rded out variable names for one thing.
> > And I think we should f=> >ix it so that that the symbols have full
> > source paths.
>=> >; > I realize they would only be correct on one machine, and hopefully <=> >BR>> > there's a decent story for copying the files.
> > Yea=> >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>=> > >
> > Other than printf'ing, I also end up getting a stack in => >cdb with no
> > symbols and then disasm in gdb to find what the f=> >unctions were. That
> > works fine a few times, but I hope not to=> > do it often. Somewhat
> > lucky I could even get a stack. Becaus=> >e, see, cdb is nice enough to
> > stop on access violations by de=> >fault (such as the time/date code was
> > causing). gdb has a pro=> >mising sounding feature, the ability to stop
> > on "signals", wh=> >ich I think an access violation would count as, oh,
> > but that => >feature isn't implemented, sorry. Ok, true, think about it
> > mo=> >re and I can break on the toplevel exception handler in
> > cygwi=> >n1.dll, not sure that always works or not, it's an
> > implementa=> >tion detail, but heck, when you are debugging, take
> > advantage=> > of whatever you have. :)
> >
> > RTIO, is too verbose fo=> >r me.
> > But darnit, I can't really have printf..puts is about th=> >e best I
> > could do..
> > Oh, but no, since TEXT !=3D => >char* even that isn't useful.
> > fread/fwrite maybe though.
&g=> >t; >
> > On a different hand (how many are there? :) ), have yo=> >u looked in
> > m3core\src\unix?
> > There is just tons => >of dead stuff, stuff with comments about it
> > perhaps being wro=> >ng, "use with care".
> > It seemed to me maybe the point was to ex=> >pose "all" of /usr/include.
> > Someone, other than me, sure seems=> > to have gone overboard, like
> > someone using Ultrix and Linux => >1.x, and then it copied around.
> > Heck, look at the mem* functio=> >ns being commented out (and probably
> > using the incorrect type=> > int) because Ultrix or somesuch didn't have
> > them. I uncommen=> >ted them to fix a build. And notice that these
> > functions, aga=> >in, like most of printf, are /extremely/ portable in
> > function=> >ality and exact binary interface (yeah yeah, I've heard of
> > bc=> >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme=> >d very possibly wrong, at least on
> > many targets, and very dou=> >btfully useful for anything, and I think
> > I've now shown unuse=> >d.
> >
> > > Y, the easiest way to implement the inter=> >face is to call a C
> > function
> > > that "just hap=> >pens" to have the correct interface. But on another
> >
> &g=> >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for=> > all languages to just understand C headers so we can stop
> > re=> >writing them...
> > Or some other language, ok...not going to be s=> >olved in this forum.
> > To go the unpopular route (again), MS CLR=> >/.NET among many other
> > things, attempts to solve this very pr=> >oblem.
> > One way to describe "interfaces" that "all" languages c=> >an
> > understand...at least for some subset of languages feature=> >s..
> >
> > Just as tedious btw, it is often more portabl=> >e to wrap all the C
> > APIs in C, exposing a portable controled => >Modula-3 interface
> > independent of the precise header content.=> > Like errno and my
> > get_stderr/out/in.
> >
> &g=> >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.=> >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g=> >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com=> >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>=> >; > >
> > >
> > > This is also an excellent r=> >eason not to permit "interfaces" to C
> > > code inlined into M=> >ODULEs.
> > >
> > > Interfaces are the contract tha=> >t the implementation has to live up
> > > to. Ok, so it happens=> > that under operating system X on architecture
> > > Y, the eas=> >iest way to implement the interface is to call a C
> > function >R>> > > that "just happens" to have the correct interface. But on => >another
> > > system, which either isn't built in C or where th=> >e function doesn't
> > > exist, it might be convenient to imple=> >ment the interface in (gasp!)
> > > Modula-3!
> > >=> >
> > > (I use this pattern as follows: on systems where Intel's=> > Fortran
> > > compiler is available, compile from assembly (wh=> >ich was generated
> > > by ifort). On other systems, the code i=> >s implemented in Modula-3.)
> > >
> > > Mika
>=> >; > >
> > > Tony Hosking writes:
> > > >My=> > principle concern is that once we provide C APIs then C will
> > => >> >permeate the M3 space more pervasively (both apps and libraries).<=> >BR>> > > >What happens when I want to bring up a system where t=> >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&=> >gt; > > >
> > > >Maybe I am just being overly fusty=> >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P=> >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g=> >t;> What we _maybe_ can do... is to make some special, preprocessable >>> > > >> source
> > > >> form, which some=> > quake command can parse into multiple files in
> > their
>=> > > > >> folders. And these file can be compiled later...Kind of=> > how
> > generic
> > > >> works.
> > &=> >gt; >>
> > > >> But, as current system works, and i=> >t does it very well, and as
> > only
> > > >> c=> >ase
> > > >> where we really need this is Windows... most=> > Unices being or
> > becoming
> > > >> POSIX...=> > I don't see it's smart to spend resources on becoming
> > more >R>> > > >> C...
> > > >> Esp when "foundin=> >g fathers" made it so good and so much non-C :).
> > > >>=> >
> > > >> If we really need to make some approach to "the=> >ir world", it's
> > much
> > > >> better to wor=> >k on interoperability issues and thus cement our
> > > >>=> > first-class-citizen language status even more.
> > > >><=> >BR>> > > >> dd
> > > >>
> > > => >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &=> >gt; > >>> Jay:
> > > >>>
> > >=> > >>> My understanding of Modula-3 is that rather than cluttering u=> >p
> > the
> > > >>> source code with a bunch=> > of preprocessor directives to deal
> > with the
> > >=> >; >>> various changes needed by various platforms, a separate sour=> >ce
> > > >>> file is
> > > >>> us=> >ed for platforms whose implementation must diverge. The
> > m3mak=> >efile
> > > >>> is used to control the selection of th=> >ese platform sources at
> > build
> > > >>> => >time. I like this approach much better.
> > > >>>
&=> >gt; > > >>> Regards,
> > > >>> Randy >>> > > >>>
> > > >>>>>> Jay=> > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g=> >t; >>> So I have NOT thought this through.
> > > >&=> >gt;>
> > > >>> I wonder if "preprocessing" dependen=> >t only on "target" is a good
> > > >>> idea.
> &=> >gt; > >>>
> > > >>> Something like either => >the ability to prefix pragmas with a
> > target, or
> > => >> >>> an "iftarget" and "ifnottarget" pragma.
> > >=> > >>>
> > > >>> Something like so:
> >=> >; > >>>
> > > >>> <* IF_TARGET NT386 *&=> >gt;
> > > >>> <* END_IF_TARGET*>
> > &g=> >t; >>>
> > > >>>
> > > >>&g=> >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_=> >TARGET*>
> > > >>> It's a small can of worms.
&g=> >t; > > >>> Where can they be placed? Only at "global" scope?=> > (ie:
> > toplevel in an
> > > >>> interface=> >/module).
> > > >>>
> > > >>> Wha=> >t about IF_OSTYPE?
> > > >>> What about expressions? >R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > => >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g=> >t; > >>>
> > > >>> etc.
> > > => >>>>
> > > >>> I don't really have enough inte=> >rest here to work through this,
> > just
> > > >&g=> >t;> sending out the bait...
> > > >>>
> > => >> >>> Obviously this was triggered by my happening into the odb=> >c
> > directory
> > > >>> and bringing up ig=> >noring WINAPI on non-NT386 or prefixing
> > calling
> > => >> >>> conventions with a target.
> > > >>>=> >
> > > >>> This reminds me of an important point here => >however -- nobody
> > else is
> > > >>> goin=> >g to make the mistake of ever having multiple calling
> > > >=> >;>> conventions.
> > > >>> Therefore the general=> >ity of prefixing WINAPI with NT386: is
> > useless.
> > => >> >>> Unless Mac68K support is added.
> > > >>=> >;>
> > > >>> And here is some rationale even. The P=> >C and Mac evolved from
> > "small"
> > > >>>=> > systems, where assembly programming was common, more people
> > => >knew more
> > > >>> lower level details and playing ga=> >mes with calling conventions
> > was
> > > >>&g=> >t; something anyone could do. Most other current systems are
> > => >rooted in C
> > > >>> programming. Working in C, calli=> >ng conventions are generally
> > in a
> > > >>&=> >gt; hidden layer below what anyone thinks about. Therefore, the
> &g=> >t; smaller
> > > >>> number of capable people working => >at that level have the good
> > sense to
> > > >&g=> >t;> only have one calling convention. No more systems will evolve
&g=> >t; > from
> > > >>> "small", at least not without h=> >aving observed this history.
> > > >>> Therefore,
&=> >gt; > > >>> there will no longer be multiple calling convent=> >ions.
> > > >>>
> > > >>> That is=> > my theory at least.
> > > >>>
> > > >&=> >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > => >__thiscall is
> > > >>> only x86
> > > >=> >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.=> >org>
> >
> >
> > Connect and share in new way=> >s with Windows Live. Get it now!
>


Shed those ext=> >ra pounds with MSN and The Biggest Loser! >n.com/' target=3D'_new'>Learn more.> >=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 14 18:31:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 12:31:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Message-ID: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: [...many other good comments deleted...] > Multiple inheritance was left out of the language after long > discussions because it was not really understood at that time. > It may be that things have changed in this respect, but I still > don't think it is. Multiple inheritance is fine so long as it encodes only type, but *not* if it encodes representation as well. Witness single inheritance for classes in Java, versus multiple inheritance for interfaces in Java. That seems to be the general consensus these days. >> To a large extent I'm just looking for a small smart group to have >> a friendly intellectual discussion with. >> (and of course, don't mess up their code) > > I think you can have that here. People are willing to discuss and > think things over, but the pace may be somewhat slower than you'd > like :-) > (It's not as bad as with Tolkien's Ents, but still ... slow :) > So, as others have noted, it's great that there is so much activity > recently, but it would still be better if the discussions and comments > were more focused on important language related content about M3. > Nobody has accused you of malicious intentions, and you've always > accepted objections and corrections by others as far as I remember. > > I think what is mostly needed is to slightly adapt your style of > working and discussing things to become better accepted here. > Don't speak out too rash, and don't commit lots of small changes > too soon. Work things out and become more self-confident about > the results of your work. I'm sure you can contribute many interesting > things to M3. Indeed, Jay, we need your Windows energy -- M3 needs to play well on Windows if it is to serve its true purpose: a language that allows applications to be written easily that also run on a multitude of platforms (POSIX, Mach/Darwin/OS X, Windows, ...). Randy is very keen to have a *stable*, easily installed, reliable, version of CM3 running on Windows. I am not sure we have reached that goal yet, even as you have put some great work into achieving that goal. I would very much encourage you to focus your efforts on achieving that kind of stability/reliability/usability for Windows. > PS: Sorry if some of the above reads as if I'm your teacher ;-) We are all padawans Obi-wan. ;-) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Thu Feb 14 19:08:35 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:08:35 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <20080214180835.GA30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 04:28:41AM +0000, Jay wrote: > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop rewriting them... > Or some other language, ok...not going to be solved in this forum. As usual, the problem has no solutions, and there are programs that solve it. It can't be solved because a lot of C headers -- especially the standard ones -- use implementation-dependent, and often undocumented, code behind the scenes. This makes it essentially impossible to define what a "C header" is for purposes of implemetation. But it has been solved, for many practical purposes, byt a program that reads C header files and generates the interface code that's needed by other languages to interface with the C code. I'm not sure of that program's name but "swix" comes to mind. Can anyone confirm that? The program possiblyknown as swix has to be configured (in a configuration file) for the particular target language. And you'd best check the output -- it may not automagically handle *everything* C compilers can throw at it. But it is useful. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:34:27 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:34:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <20080214183427.GB30167@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: > M3 is the antithesis in the sense that it takes the opposite approach. > C has few protections, M3 has many. M3 does examine what was wrong > with C and other languages and fix them and it did a good job. The M3 > design team made an explicit goal to look at features from other > languages and take the best. The fact that M3 works so well is the > proof. > > Some of the things you raise, like braces I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and 'END'. Natural languages evolve in the direction of having the mopst-oftern used words be the shortest. This makes it possible to say muc in less space and time. And it makes it easier to get an overview of a program whose physical size is becoming inconvenient. Just haveing the code be readable and seeing enough of its context makes debugging easier. > or stack allocations of > objects are just features of C++ with no justification. Stack allocation of objects is not such a big issue in C++. But it can be a big issue in those programs where split-second real-time interaction is an issue. Yes, I know this is the traditional argument against garbage collection, and that it is usually based on FUD rather than reality. But I have recently been in close contact with a programmer of video games, and for some of them the fraction-of-a-second pauses are a real problem. He really *wants* to write his games in a decent language, and he knows that C is not one. But every time he avoids heap allocation he delays the pause. If he can delay it enough, it's a win. If he can delay it altogether, that's success. > Can you show > that typing less characters is important? You say M3 is less > convenient, but what is less convenient, less typing or less bugs? This is a false dichotomy. You may well be able to reduce typing *and* reduce bugs, just by making code more readable. I doubt that typing "PROC" instead of "PROCEDURE", for example, is likely to introdice bugs. Not typing '{' instead of "BEGIN". Using special characters and lower-case keywords is likely to reduce bugs, because it's less likely that one will be misread for another. > Do > you spend most of your time typing or thinking when you write code? I think before I write code. I don't stop thinking when I start writing code, and I like to record my thoughts as I think. The less typing I need to do, the better I can get visual feedback on my thoughts while thinking. Sometimes the typing gets so tedious I get bored and lose interest. Then extra typing causes extra bugs. > > Should language include every feature anyone can think of? No. > How is > excluding unimportant features 'arbitrary'? Each feature must be > weighed to avoid unnecessary complexity and size, which have a direct > impact on compiler maintainability and language usability. Language > bloat is a real problem. I doubt that anyone understands the full > semantics of C++. > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. Enough people use it that it has become a fixture in the programming world. If you want to reuse existing code instead of always writing new, you are pretty much forced into some kind of interfacing between C and a reasonable language. The convenience of this interfacing can well determine whether the reasonable language is feasible for a specific application. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:59:47 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:59:47 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Message-ID: <20080214185947.GC30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > Not even C++ has virtual methods in stack-allocated objects does > it? To my knowledge (as former C++ implementor), it does. But such a stack-allocated variable is of statically-known actual type, so the compiler can statically resolve all virtual methods to the actual function implementing them. And it you pass the address of such an object to another function, the other function will handle its virtual methods by the usual virtual function lookup. The only real problem is that it's a bloody disaster if you try to free one of them as if it has been dynamically allocated. But that wouldn't be a problem in a garbage-collected language. > If there's a language that has a lot of arbitrary limitations > in this area it's C++. It's kind of funny: if you know Modula-3, > you start by wondering how C++ implements X, where X is a feature > you would like but M3 lacks, and then you find that while C++ does > indeed implement X', that is, X in a restricted sense, it does > actually not implement X in the full generality you'd like. And > for the same reasons that M3 doesn't touch it in the first place. > Stack-allocated objects are an example of this. If you want > stack-allocated data structures, use a RECORD and a PROCEDURE. That > will give you almost exactly the same thing that a stack-allocated > object gives you in C++! Not quite -- you lose its ability to be considered an inheritor of another class. That's a big loss. > About C++: do you *really* know C++? I was reading Stroustrup's > book a while back and after reading four or five times "if you want > to try this, ask an experienced colleague first" I gave up in disgust > on trying to understand C++. As implementor, I suppose I might be considered an experienced colleague. > There are so many odd little ways you > can go wrong in C++. Yup. That's why I like to avoid using it. > Sometimes assigning an object to a variable > causes your program to break in mysterious and horrible ways, > sometimes... It should never have allowed those potentially type-violating assignments. > C++ programmers also tend to underestimate how effective > garbage collection is in simplifying things. This is different > from saying "garbage collection helps you avoid memory management > errors" (because you say "I am a competent C++ programmer, I never > make memory management errors"). Garbage collection lets you > structure your code in ways that simply is not possible if you have > to worry about which part of it is going to allocate and which part > is going to deallocate memory. There's code I wouldn't venture to write without built-in garbage collection. C++ throws a sop at the programmer in the form of enabling him to core reference-counting in an at least semi-automatic way, but it isn't enough. -- hendrik From rodney.bates at wichita.edu Thu Feb 14 23:56:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 16:56:13 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: <47B4C70D.4010408@wichita.edu> OK. So would my proposal 1) below suffice, that the alignment rules are a property of a type and thus the same for every variable of that type? More immediately relevant, is it true that nothing that uses LAZYALIGN rules is ever pickled? I believe current pickles will trash things badly if that happens. Fixing this without invalidating existing pickles and/or compiled code looks tricky. If nothing LAZYALIGN is pickled, I am hoping to be able to come up with a scheme that will fix pickles, not require rewriting of any already existing pickle files or recompilation of existing object code, and yet not introduce any new bugs involving old pickles/code. Maybe I should just postpone this one until after LONGINT in pickles is supported (only with STRICTALIGN, as now for other types.) Darko wrote: > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures. > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > >> It sounds like all that Mac OS X needs is for _all_ types in an entire >> program to use the liberal packing rules. Have I understood correctly? >> I would have no grief over that. >> >> Darko wrote: >> >>> The liberalised alignment rules are required for the native Mac OS >>> X API and should stay. You cannot use that API without them. I >>> think the pragma is not required and can be removed. I agree with >>> all the points you make. The effect of the modified alignment rules >>> it to allow *packed* structures to have members aligned on byte >>> boundaries. This has the effect of packing the fields in the >>> tightest arrangement allowed by the platform. This might affect >>> performance, but if the user is concerned about this they should >>> specify field bit sizes that deliver improved performance. I don't >>> see a need to specify this on a structure level, for the reasons >>> you give and because the difference isn't significant enough in the >>> case of packed structures and their physical layout and >>> restrictions are platform dependent anyway. >>> I might also add that the alignment code is currently broken on >>> I386_DARWIN. >>> - Darko >>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> >>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>> being used anywhere? >>>> >>>> It is not documented in pragmas.html. The compiler front end appears >>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>> limitations on what declarations the pragma can appear on, but these >>>> are not actually enforced.) It liberalizes the alignment rules, >>>> generally allowing scalars to start on any byte boundary. >>>> >>>> Pickles have to be able to reconstruct the layout of types as the >>>> compiler would have done it for a machine (on which a now-being-read >>>> pickle was written) with different word size and alignment properties. >>>> Currently, pickles are completely unaware of lazy alignment. It >>>> would have to be encoded in type descriptions generated by the >>>> compiler >>>> using TipeDesc and read by pickles using RTTipe. >>>> >>>> Most troubling to me is what looks like a linguistic Pandora's box. >>>> The pragma can be associated with any constant, variable, or type >>>> _declaration_ (not type definition), with the result that different >>>> values of the same type can actually be different in their alignment >>>> rules and thus their layout. Similarly for different identifiers >>>> equated to the same type. Although the effects of this could possibly >>>> be hidden from the programmer in purely safe code, not so with unsafe >>>> code. I haven't thoroughly thought this through, but seems to me to >>>> really fly in the face of the whole typing philosophy of the language. >>>> >>>> For example, if pickles were to read in an object value, and there >>>> were >1 variants of the object's type in the reading program, >>>> differing >>>> only in the alignment rules, how would it decide which one to build? >>>> In fact, ignoring pickles altogether and just looking at a single >>>> program, >>>> if the object's type doesn't actually uniquely give its memory layout, >>>> how can it be accessed correctly? >>>> >>>> Additionally, a quick look at the compiler suggests it won't generate >>>> correct code for whole record assignment when the LHS and RHS are the >>>> same type but have different alignment characteristics. >>>> >>>> The more I think about it, it seems the only workable >>>> possibilities are: >>>> >>>> 1) Require the pragma to be associated only with a type >>>> _definition_ not a >>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>>> this a >>>> property of the type that propagates to all names for the type and >>>> all variables, constants, etc. Also, this would make this property >>>> a part of the type signature that pickles uses when reading, -OR- >>>> >>>> 2) Forget it altogether. >>>> >>>> What do people think? >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 00:22:06 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:22:06 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <47B4CD1E.100@wichita.edu> Detecting use of uninitialized variables statically is undecidable, although a good many specific (and common) cases can be caught or ruled out. Detecting at runtime requires a spare bit pattern that normal values of the type don't use, or an extra bit or something--not too convenient for some types. I have always been a bit ambivalent about Modula-3's rule that every variable is initialized to some unspecified bit pattern that is a valid value of the type. I understand this is the minimum requirement to ensure type safety. But for the same price already paid to do this (runtime initialization code), we could have default initialization to a language-specified value, which would make for more consistent behavior. I have been gradually expanding the habit of writing an explicit initial value on just about everything, whether bug-free code would need it or not, just for the reduced risk of unreproduceable bugs. Of course, if the type's representation uses every bit pattern, then the rule we have has no cost, whereas a language-specified initial value would. Jay wrote: ... > Java and I presume C# have a nice feature here too where they require > the compiler to error for use of uninitialized variables, though I > suspect the specced algorithm misses some things, like: > > if (...) > initialize x > > common code > > if (same thing) > use x <== possible use of uninitialize x, not > > At least I've seen other tools (not Java/C# compilers, I don't use > those) get confused by this.. >-- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 15 00:05:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:05:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: I don't want to add fuel to the fire, but .... On Feb 14, 2008, at 1:34 PM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. There are true "real-time" garbage collectors in development and deployment now that avoid applications from seeing pauses. Modula-3 is getting better in this respect, but it is still not quite there. But, fortunately, Modula-3 provides UNTRACED objects/ references which *never* themselves cause GC. In fact, for the current CM3 implementation it would be possible to have a real-time thread run and manipulate only UNTRACED references and never ever see a GC pause -- it would keep running even while other threads are caught up by GC! >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. I don't find M3 to be unreadable at all. In fact, I find it to be very readable. > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. Who types? I use an editor that completes and indents Modula-3 code with exactly the same number of keystrokes as I use when programming in C. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. And CM3 does this very well -- that does not mean we should permeate the Modula-3 space with C'isms. > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 00:06:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:06:48 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214185947.GC30167@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> Message-ID: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> PS The C++ standard committee is actively developing the next C++ standard to include garbage collection as part of the spec. The worm has turned... On Feb 14, 2008, at 1:59 PM, hendrik at topoi.pooq.com wrote: > On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > >> Not even C++ has virtual methods in stack-allocated objects does >> it? > > To my knowledge (as former C++ implementor), it does. But such a > stack-allocated variable is of statically-known actual type, so the > compiler can statically resolve all virtual methods to the actual > function implementing them. And it you pass the address of such an > object to another function, the other function will handle its virtual > methods by the usual virtual function lookup. > > The only real problem is that it's a bloody disaster if you try to > free one of them as if it has been dynamically allocated. But that > wouldn't be a problem in a garbage-collected language. > >> If there's a language that has a lot of arbitrary limitations >> in this area it's C++. It's kind of funny: if you know Modula-3, >> you start by wondering how C++ implements X, where X is a feature >> you would like but M3 lacks, and then you find that while C++ does >> indeed implement X', that is, X in a restricted sense, it does >> actually not implement X in the full generality you'd like. And >> for the same reasons that M3 doesn't touch it in the first place. >> Stack-allocated objects are an example of this. If you want >> stack-allocated data structures, use a RECORD and a PROCEDURE. That >> will give you almost exactly the same thing that a stack-allocated >> object gives you in C++! > > Not quite -- you lose its ability to be considered an inheritor of > another class. That's a big loss. > >> About C++: do you *really* know C++? I was reading Stroustrup's >> book a while back and after reading four or five times "if you want >> to try this, ask an experienced colleague first" I gave up in disgust >> on trying to understand C++. > > As implementor, I suppose I might be considered an experienced > colleague. > >> There are so many odd little ways you >> can go wrong in C++. > > Yup. That's why I like to avoid using it. > >> Sometimes assigning an object to a variable >> causes your program to break in mysterious and horrible ways, >> sometimes... > > It should never have allowed those potentially type-violating > assignments. > >> C++ programmers also tend to underestimate how effective >> garbage collection is in simplifying things. This is different >> from saying "garbage collection helps you avoid memory management >> errors" (because you say "I am a competent C++ programmer, I never >> make memory management errors"). Garbage collection lets you >> structure your code in ways that simply is not possible if you have >> to worry about which part of it is going to allocate and which part >> is going to deallocate memory. > > There's code I wouldn't venture to write without built-in garbage > collection. C++ throws a sop at the programmer in the form of > enabling > him to core reference-counting in an at least semi-automatic way, > but it > isn't enough. > > -- hendrik From rodney.bates at wichita.edu Fri Feb 15 00:32:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:32:57 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <47B4CFA9.2060400@wichita.edu> Whether you agree with their conclusions or not, the designers of Modula-3 and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing just that. Despite having a few complaints and ambivalences here and there, I for one, think the final result is unmatched for the ways it made all the very difficult tradeoffs among highly contradictory desiderata. Jay wrote: .... > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. .... > If you start over completely from scratch, you should still look at what > is out there. -- ------------------------------------------------------------- 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 hosking at cs.purdue.edu Fri Feb 15 00:18:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:18:32 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> Why is LONGINT for pickles not yet supported? On Feb 14, 2008, at 5:56 PM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment > rules are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any > already existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in > pickles is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible >> with C and Unix interfaces. The alignment change was implemented >> to be supported only in packed structures as a natural and >> intuitive way to "force" alignment. You could view it as a bug >> fix to overly restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without >>>> them. I think the pragma is not required and can be removed. I >>>> agree with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have >>>> members aligned on byte boundaries. This has the effect of >>>> packing the fields in the tightest arrangement allowed by the >>>> platform. This might affect performance, but if the user is >>>> concerned about this they should specify field bit sizes that >>>> deliver improved performance. I don't see a need to specify >>>> this on a structure level, for the reasons you give and >>>> because the difference isn't significant enough in the case of >>>> packed structures and their physical layout and restrictions >>>> are platform dependent anyway. >>>> I might also add that the alignment code is currently broken >>>> on I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by >>>>> the compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type >>>>> and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 darko at darko.org Fri Feb 15 00:26:23 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:26:23 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> The alignment rules are correctly associated with a type. I think the pragma can be removed. There are no pickles anywhere of these types. On 15/02/2008, at 9:56 AM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment rules > are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any already > existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in pickles > is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible with >> C and Unix interfaces. The alignment change was implemented to be >> supported only in packed structures as a natural and intuitive way >> to "force" alignment. You could view it as a bug fix to overly >> restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without them. >>>> I think the pragma is not required and can be removed. I agree >>>> with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have members >>>> aligned on byte boundaries. This has the effect of packing the >>>> fields in the tightest arrangement allowed by the platform. >>>> This might affect performance, but if the user is concerned >>>> about this they should specify field bit sizes that deliver >>>> improved performance. I don't see a need to specify this on a >>>> structure level, for the reasons you give and because the >>>> difference isn't significant enough in the case of packed >>>> structures and their physical layout and restrictions are >>>> platform dependent anyway. >>>> I might also add that the alignment code is currently broken on >>>> I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by the >>>>> compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > -- > ------------------------------------------------------------- > 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 Fri Feb 15 00:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:31:03 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: > I don't want to add fuel to the fire, but .... > there. But, fortunately, Modula-3 provides UNTRACED objects/ > references which *never* themselves cause GC. In fact, for the Right, "optional safety" is a nice feature of Modula-3. C# has optional safety but I think maybe in fewer ways -- optional integer overflow checks, not sure what else. Otherwise optional safety seems to be pretty rare. This does remind us -- I don't think Modula-3's integer overflow rules are as obviously safe as they could be. I think it's a target-varying thing and most targets don't check. Integer overflow has started to become a concern like buffer overflow..so probably something should be done. HOWEVER something pervasive and automatic may be too risky in terms of compatibilty with existing code. I mean Modula-3. In C and C++, for "useful suggestions", there have been two obvious patterns: Functions to add, subtract, multiple integers, that can fail. Tedious but explicit. Probably good candidates for building into the language/compiler like Word, even if they are explicit functions. Templatized types with all the operators overloaded. Also a good candidate for inclusion in the language/compiler. What to call? There is "SafeInt". I think Modula-3 has more chance of getting away with just making it so for INTEGER but I would have to read up more. In C as I understand: The encoding and overflow behavior of signed integers is undefined/implemention-defined. You could have signed magnitude, one's complement, two's complement, or anything you want. You can have any behavior for integer overflow. Some sort of "wrap around", abort(), etc. For unsigned integers, overflow is well defined, never an error, and "wraps around". In practise, signed integers are always two's complement, overflow is never an error, and "wraps around", the same or nearly the same as unsigned integers. "Wrap around" being better defined as results are taken modulo 2^(bitsize(the type)). Signed and unsigned operations often generate identical code, but not always. For example add and subtract are often identical. Comparison can be identical and then use a different conditional branch. I'm just being lazy here, if I really dig into it I could remember/re-derive the rules, though I don't know the instructions sets. (on 6502, the compare instruction only works for unsigned, you have to subtract and destroy a register, of which there are only three, though another point of view considers memory, or certain memory, as registers, yes I know that sounds plain wrong, but when all you have is a,x,y and single byte addresses have more features (addressing modes) than larger addresses...). - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 00:35:52 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:35:52 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: > From: rodney.bates at wichita.edu> > Whether you agree with their conclusions or not, the designers of Modula-3> and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing The end of Nelson's book is VERY interesting in this regard, "How Modula-3 got its spots". I had previously never thought about type name vs. structural equivalence, or even knew to ask about them. - Noam :) _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Feb 15 00:47:01 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:47:01 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> I don't really question the usefulness of any given feature, just the incremental cost of adding any given feature. One of M3's great strengths is that it is low on features, but the ones it has are powerful and well chosen. The comparison I meant in the typing discussion was between C and M3, not the length of symbols. C is a bit obsessive about source size, which was meaningful back in the day, but today is totally irrelevant. Even if you don't use macros on your editor, the amount of time spent staring and your code is much greater than the time you spend typing it. You could argue that BEGIN/END is easier to read than {/} but I think the more important point is that this issue is not a significant one. On 15/02/2008, at 5:34 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. > > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. > > -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:18:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:18:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <20080215141819.GB3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} If I had to argue, I'd argue the reverse. In fact, if it weren't for disputes about the number of spaces that are equivalent to a tab and such, I'd argue for using indentation and dispensing with BEGIN/END/{/} altogether. Somewhere I have a C++ program with all the braces left out. If you manage to supply the right braces and get it compiled, you end up with a program that will do the job of supplying the right braces. I could post it here if anyone in interested in such a curiosity. There's one language I've seen that goes in the opposite direction. Every END is followed by an arbitrary amount of text from the start of the construct it closes and a semicolon. This a WHILE loop starting WHILE toronto == montreal could end with END WHILE toronto ==; making visual matchin unambiguous. I've got friends that complain about haveing to type the name if a procerure twice in its declaration -- once at the start and once at the end. They say they keep fprgetting to modify both. But I welcome this as a useful check on long-range bracket matching. Forcing it for short-range marching, though, is clutter. -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:20:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:20:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> Message-ID: <20080215142042.GC3639@topoi.pooq.com> On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: > PS The C++ standard committee is actively developing the next C++ > standard to include garbage collection as part of the spec. What are they ever going to do with those autodecremented pointers into the middle of arrays? -- hendrik From jayk123 at hotmail.com Fri Feb 15 16:10:16 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:10:16 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: Having written a bit of Python..really just a bit..you are all privy to ALL of the Python I have ever written...I'll bite. It's fairly obvious once you write a bit of Python what goes on here. First, we all know that we all strive to indent things "correctly". Now, "correctly" can vary somewhat, but the intent is universal. Deeper lexical nesting goes with increased indentation. You can pick the indent size, spaces vs. tabs, where the braces/begin/end go, but it's still the same intent. Now, when paired with begin/end or braces, you end up with a large duplication of information. The one the compiler uses only and the ones human use more. You get to keep them in sync. Your editor might help a lot. What Python does is merely throw out half the data, and require some consistency on your part for what in other languages the compiler ignores. I don't know the exact rules, but they are probably easy to think of. That is, it could easily allow either spaces or tabs. This approach is not bad. But I have two problems: 1) again, my editor 2) it's a little wierd and hard to see when you have a whole lot of closes in a row if print if print if print nothing here vs. either C or Modula-3. Perhaps a better approach is to require "end" and require consistent indentation. Python also can't cope with an empty statement because of this plus its lack of semicolons. You have to say "pass". That's a bit of an indictment. As to tabs, the answer is very easy. Never ever use them. Lots of folks use 4 space tabs, lots of folks use 8 space tabs. I used to be a 4 space tab guy, but I gave up tabs a few years ago. The Cygwin code uses 8 space tabs and is therefore unreadable to me. (I could change my editor setting, and since the 4 space tabs are pretty rare now, ok.) To those who suggested emacs for convenient Modula-3 editing, sorry, it's not likely going to happen. I have tried vi and emacs multiple times through the years and I can't use either. I use vi just for editing commit comments, which are often pasted in to the console from notepad anyway. My "problem" is that I make heavy use of the arrows, home, end, page up, page down, control, and shift. (control can "accelerate" arrows, shift is used for selecting). And some other ingrained keyboard short cuts like control-f, F3, etc. I use Visual C++ 5.0 and its support for these keys, plus a little bit of support for indentation, is excellent. It could be that the newer versions are better, and I would like find-and-REPLACE in files, and support for unicode files, but these aren't worth it so far. Oh, and the find-in-files, minus a replace option, is excellent, just super duper, I use it constantly. Nothing else compares. The only people I try to get to change editors is people that use notepad. On PPC_DARWIN I make do with TextWrangler. It is ok. (From the BBEdit folks). On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. If anyone out there is struggling with too-basic editors such as TextEdit or whatever it's called these days, I'd recommend trying these. But if you are already using a "programmer's editor", I'll leave you alone. :) If anyone knows of something more comparable to Visual C++ 5.0 on other platforms, I'm eager to hear. (Maybe under Wine? But that requires x86 I think..) Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), but it starts up slowly on Windows, crashes a bit on Windows, and isn't being updated.. (Trying for "gentle advise" not "advocacy" here.) > > incremental cost of adding any given feature. One of M3's great I think the problem is more of multiplication than increment. How do the features interact with each other? Two features interact very very well -- destructors and exceptions. And constructors in that mix. Otherwise not certain. > C is a bit obsessive about source size, There used to be an assembler that used tabs and a competitor that used spaces. The tab guy advertised his much smaller files. :) And I think therefore faster assembling. Well, definitely much faster assembling either way, probably not because of or only because of the tabs. Yes I have that problem with procedures. And modules, and interfaces. This is where my editor and braces excel. You need to sprinkle in the matching text. You type control-brace on a brace and it shows you the matching one. Some editors do this just by moving the cursor across a brace (or paren). - Jay > Date: Fri, 15 Feb 2008 09:18:19 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote:> > I don't really question the usefulness of any given feature, just the > > incremental cost of adding any given feature. One of M3's great > > strengths is that it is low on features, but the ones it has are > > powerful and well chosen.> > > > The comparison I meant in the typing discussion was between C and M3, > > not the length of symbols. C is a bit obsessive about source size, > > which was meaningful back in the day, but today is totally irrelevant. > > Even if you don't use macros on your editor, the amount of time spent > > staring and your code is much greater than the time you spend typing > > it. You could argue that BEGIN/END is easier to read than {/}> > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/{/} > altogether.> > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces.> I could post it here if anyone in interested in such a curiosity.> > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting> WHILE toronto == montreal > could end with> END WHILE toronto ==;> making visual matchin unambiguous.> > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at the > end. They say they keep fprgetting to modify both. But I welcome this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 16:18:11 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:18:11 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. I do NOT assume existing code will get garbage collection without source change. But then again, what does the Boehm collector do? And if I write: a: array of integer; for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not what I'm used to...*) IO.PutInt(a[i]); end in Modula-3, is the codegen a) really banned from and b) really avoids "rewriting" that with pointer arithmetic? I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: unsigned array[n]; for (size_t i = 0 ; i != n ; ++i) { printf("%u\n", array[i]); } vs. unsigned array[n]; for (unsigned* p = array ; p != (array + n) ; ++p) { printf("%u\n", *p); } compilers can often do better with the first. I've heard this. I don't know why. - Jay > Date: Fri, 15 Feb 2008 09:20:42 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote:> > PS The C++ standard committee is actively developing the next C++ > > standard to include garbage collection as part of the spec.> > What are they ever going to do with those autodecremented pointers into > the middle of arrays?> > -- hendrik _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Feb 15 16:31:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 10:31:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <20080215153142.GD3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:18:11PM +0000, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. > I do NOT assume existing code will get garbage collection without source change. > But then again, what does the Boehm collector do? I don't know. I'm mostly pointing out that it will involve radical change in C++ usage. > I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: > > unsigned array[n]; > for (size_t i = 0 ; i != n ; ++i) > { printf("%u\n", array[i]); > } > > vs. > unsigned array[n]; > for (unsigned* p = array ; p != (array + n) ; ++p) > { > printf("%u\n", *p); > } > > compilers can often do better with the first. I've heard this. I don't > know why. Perhaps because it's easier to tell that array[i] is (supposed to be) within the array? I believe C spec requires this (except for some futzing with the address just one element past the array, like array+n) but it's never checked in any C compiler I know of. I once explored the possibility of performing all of these chacks in a C/C++ implementation, and concluded that it would require sufficiently different data representation from the programmers' expectations that it would be essentially useless. One of the main uses of C is to communicate with strange program libraries that use strange in-memory data structures. When they include garbage-collection into C++, I fear the result will be that in the absence of type-safety and array-bound safety, garbage collection will seem to be one more thing that causes programs to crash. -- hendrik From hosking at cs.purdue.edu Fri Feb 15 16:51:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 10:51:43 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B50EDF.8060807@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> Message-ID: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Ah, OK. I don't much delve in pickle-land. Anything I can help with? On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > 1) RTPacking.T and needs to have a separate size for LONGINT, > (which can vary independently of the size of INTEGER). > 2) Variable length values of subrange bounds found in type > descriptions (in TipeDesc.i3) can now have values beyond > what the native word size can represent. > 3) RTType.Kind.Longint (which I presume you, Tony, added recently) > is not handled by Pickles. > > I have done some coding on this, but have been interrupted. > > Tony Hosking wrote: >> Why is LONGINT for pickles not yet supported? > > -- > ------------------------------------------------------------- > 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 hosking at cs.purdue.edu Fri Feb 15 17:13:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:13:53 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <0F7203EA-6D0B-4A5D-BF81-0141ADDFC89A@cs.purdue.edu> Interior references are derived from base pointers -- they can be dealt with or treated conservatively. On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:14:36 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:14:36 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54D818D0-97A3-494E-A329-13690DF2466E@cs.purdue.edu> PS CM3 permits interior pointers into the middle of arrays. The only way they get generated is with VAR parameters, but they do exist. :-) On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:15:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:15:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <1AAD7E29-676A-4C45-93D5-7B52D08968BE@cs.purdue.edu> The directions of these postings are off-topic for the m3devel mailing list. Let's try to get back to questions of Modula-3 development. On Feb 15, 2008, at 10:10 AM, Jay wrote: > Having written a bit of Python..really just a bit..you are all > privy to ALL of the Python I have ever written...I'll bite. > > It's fairly obvious once you write a bit of Python what goes on here. > > First, we all know that we all strive to indent things "correctly". > Now, "correctly" can vary somewhat, but the intent is universal. > Deeper lexical nesting goes with increased indentation. > You can pick the indent size, spaces vs. tabs, where the braces/ > begin/end go, but it's still the same intent. > > Now, when paired with begin/end or braces, you end up with a large > duplication of information. > The one the compiler uses only and the ones human use more. > You get to keep them in sync. Your editor might help a lot. > > What Python does is merely throw out half the data, and require > some consistency on your part for what in other languages the > compiler ignores. > I don't know the exact rules, but they are probably easy to think of. > That is, it could easily allow either spaces or tabs. > > This approach is not bad. But I have two problems: > 1) again, my editor > 2) it's a little wierd and hard to see when you have a whole lot of > closes in a row > > if > print > if > print > if > print > nothing here > > vs. either C or Modula-3. > Perhaps a better approach is to require "end" and require > consistent indentation. > Python also can't cope with an empty statement because of this plus > its lack of semicolons. > You have to say "pass". That's a bit of an indictment. > > As to tabs, the answer is very easy. Never ever use them. > Lots of folks use 4 space tabs, lots of folks use 8 space tabs. > I used to be a 4 space tab guy, but I gave up tabs a few years ago. > The Cygwin code uses 8 space tabs and is therefore unreadable to me. > (I could change my editor setting, and since the 4 space tabs are > pretty rare now, ok.) > > To those who suggested emacs for convenient Modula-3 editing, > sorry, it's not likely going to happen. > I have tried vi and emacs multiple times through the years and I > can't use either. > I use vi just for editing commit comments, which are often pasted > in to the console from notepad anyway. > > My "problem" is that I make heavy use of the arrows, home, end, > page up, page down, control, and shift. > (control can "accelerate" arrows, shift is used for selecting). > And some other ingrained keyboard short cuts like control-f, F3, etc. > I use Visual C++ 5.0 and its support for these keys, plus a little > bit of support for indentation, is excellent. > It could be that the newer versions are better, and I would like > find-and-REPLACE in files, and support for unicode files, but these > aren't worth it so far. Oh, and the find-in-files, minus a replace > option, is excellent, just super duper, I use it constantly. > Nothing else compares. > > The only people I try to get to change editors is people that use > notepad. > > On PPC_DARWIN I make do with TextWrangler. It is ok. (From the > BBEdit folks). > On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. > > If anyone out there is struggling with too-basic editors such as > TextEdit or whatever it's called these days, I'd recommend trying > these. But if you are already using a "programmer's editor", I'll > leave you alone. :) > If anyone knows of something more comparable to Visual C++ 5.0 on > other platforms, I'm eager to hear. > (Maybe under Wine? But that requires x86 I think..) > > Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), > but it starts up slowly on Windows, crashes a bit on Windows, and > isn't being updated.. > > (Trying for "gentle advise" not "advocacy" here.) > > > > incremental cost of adding any given feature. One of M3's great > > I think the problem is more of multiplication than increment. > How do the features interact with each other? > Two features interact very very well -- destructors and exceptions. > And constructors in that mix. > Otherwise not certain. > > > C is a bit obsessive about source size, > > There used to be an assembler that used tabs and a competitor that > used spaces. > The tab guy advertised his much smaller files. :) And I think > therefore faster assembling. > Well, definitely much faster assembling either way, probably not > because of or only because > of the tabs. > > Yes I have that problem with procedures. And modules, and interfaces. > This is where my editor and braces excel. You need to sprinkle in > the matching text. > You type control-brace on a brace and it shows you the matching one. > Some editors do this just by moving the cursor across a brace (or > paren). > > - Jay > > > > > Date: Fri, 15 Feb 2008 09:18:19 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > > > I don't really question the usefulness of any given feature, > just the > > > incremental cost of adding any given feature. One of M3's great > > > strengths is that it is low on features, but the ones it has are > > > powerful and well chosen. > > > > > > The comparison I meant in the typing discussion was between C > and M3, > > > not the length of symbols. C is a bit obsessive about source size, > > > which was meaningful back in the day, but today is totally > irrelevant. > > > Even if you don't use macros on your editor, the amount of time > spent > > > staring and your code is much greater than the time you spend > typing > > > it. You could argue that BEGIN/END is easier to read than {/} > > > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > > disputes about the number of spaces that are equivalent to a tab and > > such, I'd argue for using indentation and dispensing with BEGIN/ > END/{/} > > altogether. > > > > Somewhere I have a C++ program with all the braces left out. If you > > manage to supply the right braces and get it compiled, you end up > > with a program that will do the job of supplying the right braces. > > I could post it here if anyone in interested in such a curiosity. > > > > There's one language I've seen that goes in the opposite direction. > > Every END is followed by an arbitrary amount of text from the > start of > > the construct it closes and a semicolon. This a WHILE loop starting > > WHILE toronto == montreal > > could end with > > END WHILE toronto ==; > > making visual matchin unambiguous. > > > > I've got friends that complain about haveing to type the name if a > > procerure twice in its declaration -- once at the start and once > at the > > end. They say they keep fprgetting to modify both. But I welcome > this > > as a useful check on long-range bracket matching. Forcing it for > > short-range marching, though, is clutter. > > > > -- hendrik > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Fri Feb 15 17:20:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:20:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54998599-6E3D-425C-BA89-7BABBD9508D6@cs.purdue.edu> On Feb 15, 2008, at 10:18 AM, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on > pointers to garbage collected types. If you check the C standard you will see that the only *defined* pointers to array elements are to the elements of the array and the "element" one index beyond the end of the array. Implementations of C are technically free to treat other pointer arithmetic however they like... :-) > I do NOT assume existing code will get garbage collection without > source change. > But then again, what does the Boehm collector do? > > And if I write: > > a: array of integer; > for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not > what I'm used to...*) > IO.PutInt(a[i]); > end > > in Modula-3, is the codegen a) really banned from and b) really avoids > "rewriting" that with pointer arithmetic? Not banned at all with the current GC. So long as a derived reference to the array exists the GC will use it to keep the array alive. From hosking at cs.purdue.edu Fri Feb 15 17:28:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:28:26 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: Rodney, Why does there need to be an entry for LONGINT in RTPacking? I would have thought all packing is done on word-sized units anyway. Each side of the connection can check BITSIZE(LONGINT) to figure out what to do presumably no differently from the way INTEGER is communicated between 32-bit and 64-bit machines. Am I missing something? -- Tony On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > Ah, OK. I don't much delve in pickle-land. Anything I can help with? > > On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >> 1) RTPacking.T and needs to have a separate size for LONGINT, >> (which can vary independently of the size of INTEGER). >> 2) Variable length values of subrange bounds found in type >> descriptions (in TipeDesc.i3) can now have values beyond >> what the native word size can represent. >> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >> is not handled by Pickles. >> >> I have done some coding on this, but have been interrupted. >> >> Tony Hosking wrote: >>> Why is LONGINT for pickles not yet supported? >> >> -- >> ------------------------------------------------------------- >> 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 rodney.bates at wichita.edu Fri Feb 15 21:50:27 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 14:50:27 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: <47B5FB13.7070407@wichita.edu> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, etc. only works for getting object layouts as on the machine executing the code, which is all that is needed when writing a pickle. When reading, Pickle code needs to know the layouts of a type both as it is on the reading machine and as it was on the machine that wrote the pickle. The type description that the compiler generates is excerpted and contains no field displacements, just lists of field types (which are either recursive type descriptions or builtin types). So it is independent of word sizes, etc. Pickles regenerates the displacements using the few target machine characteristics in a RTPacking.T It traverses a type description and simultaneously computes two sets of field displacements, both as they are on the reading machine and on the writing machine. For the latter, the value of RTPacking.T is (after a compact bit encoding) stored in the header of the pickle file. For the former, it's gotten by techniques like using BITSIZE. This is actually all done in RTTipe, part of m3core, and called by Pickle code. This is very fragile. RTTipe has to duplicate the compiler's layout behavior. There is no shared code. Making it common would involve quite a bit of rework, as the two use substantially different data structure and code organization. It will be obvious what kind of bit damage could occur if the two algorithms didn't agree. This is why I am obsessing over LAZYALIGN. I have been comparing the field displacement computations in RTTipe and in the compiler. The former is oblivious to LAZYALIGN. Note that all this is required even without any packing of small fields within words. E.G., a record with two INTEGER fields, pickled on a 32-bit machine and unpickled on a 64. Tony Hosking wrote: > Rodney, > > Why does there need to be an entry for LONGINT in RTPacking? I would > have thought all packing is done on word-sized units anyway. Each side > of the connection can check BITSIZE(LONGINT) to figure out what to do > presumably no differently from the way INTEGER is communicated between > 32-bit and 64-bit machines. Am I missing something? > > -- Tony > > On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >> >> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >> >>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>> (which can vary independently of the size of INTEGER). >>> 2) Variable length values of subrange bounds found in type >>> descriptions (in TipeDesc.i3) can now have values beyond >>> what the native word size can represent. >>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>> is not handled by Pickles. >>> >>> I have done some coding on this, but have been interrupted. >>> >>> Tony Hosking wrote: >>> >>>> Why is LONGINT for pickles not yet supported? >>> >>> >>> -- >>> ------------------------------------------------------------- >>> 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 > > > -- ------------------------------------------------------------- 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 Fri Feb 15 22:32:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 15 Feb 2008 22:32:05 +0100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B5FB13.7070407@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> Message-ID: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Perhaps we should check-in this description somewhere near the actual code? Or is there enough documentation already? Olaf PS: Based on your description, I'd say we should abandon LAZYALIGN. Or at least put a big sticker on that it will break pickles. Quoting "Rodney M. Bates" : > The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, > etc. only works for getting object layouts as on the machine executing > the code, which is all that is needed when writing a pickle. > > When reading, Pickle code needs to know the layouts of a type both as > it is on the reading machine and as it was on the machine that wrote > the pickle. The type description that the compiler generates is > excerpted and contains no field displacements, just lists of field > types (which are either recursive type descriptions or builtin types). > So it is independent of word sizes, etc. > > Pickles regenerates the displacements using the few target machine > characteristics in a RTPacking.T It traverses a type description and > simultaneously computes two sets of field displacements, both as they > are on the reading machine and on the writing machine. For the latter, > the value of RTPacking.T is (after a compact bit encoding) stored in the > header of the pickle file. For the former, it's gotten by techniques like > using BITSIZE. This is actually all done in RTTipe, part of m3core, and > called by Pickle code. > > This is very fragile. RTTipe has to duplicate the compiler's layout > behavior. There is no shared code. Making it common would involve > quite a bit of rework, as the two use substantially different data > structure and code organization. It will be obvious what kind of bit > damage could occur if the two algorithms didn't agree. > > This is why I am obsessing over LAZYALIGN. I have been comparing the > field displacement computations in RTTipe and in the compiler. The > former is oblivious to LAZYALIGN. > > Note that all this is required even without any packing of small fields > within words. E.G., a record with two INTEGER fields, pickled on a > 32-bit machine and unpickled on a 64. > > Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I >> would have thought all packing is done on word-sized units anyway. >> Each side of the connection can check BITSIZE(LONGINT) to figure >> out what to do presumably no differently from the way INTEGER is >> communicated between 32-bit and 64-bit machines. Am I missing >> something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> > > -- > ------------------------------------------------------------- > 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 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Feb 15 23:06:24 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:06:24 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Message-ID: <47B60CE0.8050506@wichita.edu> I'll put it in comments in the code. I am sure I can fix it to handle LAZYALIGN too, just not sure whether I can do it without requiring existing pickle files to be regenerated and/or existing code that reads/writes pickles to need recompilation. Anybody on this list who has code that might be affected if pickles or compiled code were invalidated by a change? I do propose we change the way of telling the compiler to do LAZYALIGN so that it is a property of a type and affects all variables of that type. Olaf Wagner wrote: > Perhaps we should check-in this description somewhere near the > actual code? Or is there enough documentation already? > > Olaf > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > Or at least put a big sticker on that it will break pickles. > > Quoting "Rodney M. Bates" : > >> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >> etc. only works for getting object layouts as on the machine executing >> the code, which is all that is needed when writing a pickle. >> >> When reading, Pickle code needs to know the layouts of a type both as >> it is on the reading machine and as it was on the machine that wrote >> the pickle. The type description that the compiler generates is >> excerpted and contains no field displacements, just lists of field >> types (which are either recursive type descriptions or builtin types). >> So it is independent of word sizes, etc. >> >> Pickles regenerates the displacements using the few target machine >> characteristics in a RTPacking.T It traverses a type description and >> simultaneously computes two sets of field displacements, both as they >> are on the reading machine and on the writing machine. For the latter, >> the value of RTPacking.T is (after a compact bit encoding) stored in the >> header of the pickle file. For the former, it's gotten by techniques >> like >> using BITSIZE. This is actually all done in RTTipe, part of m3core, and >> called by Pickle code. >> >> This is very fragile. RTTipe has to duplicate the compiler's layout >> behavior. There is no shared code. Making it common would involve >> quite a bit of rework, as the two use substantially different data >> structure and code organization. It will be obvious what kind of bit >> damage could occur if the two algorithms didn't agree. >> >> This is why I am obsessing over LAZYALIGN. I have been comparing the >> field displacement computations in RTTipe and in the compiler. The >> former is oblivious to LAZYALIGN. >> >> Note that all this is required even without any packing of small fields >> within words. E.G., a record with two INTEGER fields, pickled on a >> 32-bit machine and unpickled on a 64. >> >> Tony Hosking wrote: >> >>> Rodney, >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> would have thought all packing is done on word-sized units anyway. >>> Each side of the connection can check BITSIZE(LONGINT) to figure >>> out what to do presumably no differently from the way INTEGER is >>> communicated between 32-bit and 64-bit machines. Am I missing >>> something? >>> >>> -- Tony >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> (which can vary independently of the size of INTEGER). >>>>> 2) Variable length values of subrange bounds found in type >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> what the native word size can represent. >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>>> is not handled by Pickles. >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> >>> >> >> -- >> ------------------------------------------------------------- >> 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 > > > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:08:46 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:08:46 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> Message-ID: <47B60D6E.8080704@wichita.edu> So how is lazy alignment invoked for these types? In my grepping and reading in the compiler, I saw internal lazy alignment booleans turned on only by the pragma. Darko wrote: > The alignment rules are correctly associated with a type. I think the > pragma can be removed. There are no pickles anywhere of these types. > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:41:09 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:41:09 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <47B61505.5080708@wichita.edu> I view this as more significant than it would first appear. More important than readability is that delimiters with several letters in all caps are more PROMINENT. This makes it quicker seeing the overall structure of a piece of code before looking at the deeper details such as which variable is being manipulated. Up to now, every person I have discussed it with who has spent enough time coding with this style of delimiters to get over their initial aversion has agreed the prominence of all caps makes the code structure easier to see quickly. Even Ada programmers who had significant prior experience in Modula-2 have preferred all caps in Ada (Ada is case- insensitive, so you can do it as you please.) As for readability, I recall seeing research some years back that showed all caps are less readable than lower case, that is, people read all caps slower and/or with less accuracy. For the delimiters, prominence is more important, especially since their vocabulary is far smaller than that of identifiers and doesn't change from program to program. As for esthetics, speaking for myself, after many years, I still think all caps reserved words are uglier than mud fences, but I happily accept that as the cost of easier scanning of code. It would be nice we had a standard character code that could handle lower case, bold face, as in the Algol 60 "publication language". That would be prominent and look great too. Of course, someone could undermine it all by making all the identifiers all caps too, loosing the quickly spotted reserved words, reducing readability where it matters more, and, IMO looking even uglier. Fortunately, Modula-3 culture seems to prevent that. Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} but I > think the more important point is that this issue is not a significant > one. -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 15 23:52:22 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:52:22 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <47B617A6.80305@wichita.edu> Darko wrote: > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. "It's what everybody is doing" motivates lemmings to jump off cliffs into the ocean and drown (according to the apparently exaggerated legend.) Thinking people need better reasons than popularity. > You have to do more than list features of C or C++ and your opinions on > them. You have to provide some rationale as to their benefit which > convinces people. Sadly, in my experience, most people are so deeply committed to lemming logic, that any attempt at engaging them in a polite but serious discussion about programming languages or giving real rationale is almost always dismissed, either as "That's just religion", or "This is what everybody is doing, ergo it has to be the right way." -- ------------------------------------------------------------- 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 mika at async.caltech.edu Fri Feb 15 23:58:55 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 14:58:55 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 13:34:27 EST." <20080214183427.GB30167@topoi.pooq.com> Message-ID: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> I just have to add a small comment on syntax, in response to how weird M3's syntax is, etc. One of the nice thing when I was teaching intro programming was that "serious" CS books (and a large fraction of academic publications) still use a kind of standard pseudocode that is based on Algol. And that pseudocode looks a lot more like Modula-3 than it looks like C! No explanation of braces or the fact that when you see "=" in the pseudocode you want "==" in the machine-readable version, and when you see ":=" you want "=". What your video game developer friend needs is to do exercise #12 in section 2.3.5 in Knuth. (There are references to three existing solutions in the answer key.) Mika hendrik at topoi.pooq.com writes: >On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > >I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and >'END'. > >Natural languages evolve in the direction of having the mopst-oftern >used words be the shortest. This makes it possible to say muc in less >space and time. And it makes it easier to get an overview of a >program whose physical size is becoming inconvenient. Just haveing >the code be readable and seeing enough of its context makes >debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > >Stack allocation of objects is not such a big issue in C++. But it can >be a big issue in those programs where split-second real-time >interaction is an issue. Yes, I know this is the traditional argument >against garbage collection, and that it is usually based on FUD rather >than reality. But I have recently been in close contact with a >programmer of video games, and for some of them the fraction-of-a-second >pauses are a real problem. He really *wants* to write his games in a >decent language, and he knows that C is not one. > >But every time he avoids heap allocation he delays the pause. If >he can delay it enough, it's a win. If he can delay it altogether, >that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing >*and* reduce bugs, just by making code more readable. > >I doubt that typing "PROC" instead of "PROCEDURE", for example, is >likely to introdice bugs. Not typing '{' instead of "BEGIN". Using >special characters and lower-case keywords is likely to reduce bugs, >because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > >I think before I write code. I don't stop thinking when I start >writing code, and I like to record my thoughts as I think. The less >typing I need to do, the better I can get visual feedback on my >thoughts while thinking. Sometimes the typing gets so tedious I get >bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > >No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > >Enough people use it that it has become a fixture in the programming >world. If you want to reuse existing code instead of always writing >new, you are pretty much forced into some kind of interfacing between C >and a reasonable language. The convenience of this interfacing can well >determine whether the reasonable language is feasible for a specific >application. > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 00:17:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 18:17:41 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> References: <20080214183427.GB30167@topoi.pooq.com> <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> Message-ID: <20080215231741.GA4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: > > What your video game developer friend needs is to do exercise #12 > in section 2.3.5 in Knuth. (There are references to three existing > solutions in the answer key.) Is that the one one completely concurrent garbage collection? Unfortunately, he wants to write video games, not implement programming languages. But ... I think he's tempted. I still feel I have to warn him of the time I wanted to write an applocation and got side-tracked into writing the language in which the application would be easy to write. I never got back to the application. I don't even remember what it was. That was in the 1960's. I'm still stuck on languages. -- hendrik From darko at darko.org Sat Feb 16 00:34:47 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:34:47 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <25955172-E857-4B24-8D51-3701C7353687@darko.org> I'm sticking to my view about lexical arbitrariness, but on that basis, I'd really like to see an alternate syntax for M3, one that looks almost exactly like C, but roughly keeps the existing statement form. I think it would make the language much more palatable to C programmers and the like and would remove what is a silly barrier to broader adaption. We could call the syntax 'Modula-C'. On 16/02/2008, at 1:18 AM, hendrik at topoi.pooq.com wrote: > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: >> I don't really question the usefulness of any given feature, just the >> incremental cost of adding any given feature. One of M3's great >> strengths is that it is low on features, but the ones it has are >> powerful and well chosen. >> >> The comparison I meant in the typing discussion was between C and M3, >> not the length of symbols. C is a bit obsessive about source size, >> which was meaningful back in the day, but today is totally >> irrelevant. >> Even if you don't use macros on your editor, the amount of time spent >> staring and your code is much greater than the time you spend typing >> it. You could argue that BEGIN/END is easier to read than {/} > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/ > {/} > altogether. > > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces. > I could post it here if anyone in interested in such a curiosity. > > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting > WHILE toronto == montreal > could end with > END WHILE toronto ==; > making visual matchin unambiguous. > > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at > the > end. They say they keep fprgetting to modify both. But I welcome > this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter. > > -- hendrik From mika at async.caltech.edu Sat Feb 16 00:38:09 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:38:09 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Fri, 15 Feb 2008 14:50:27 CST." <47B5FB13.7070407@wichita.edu> Message-ID: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Hi Rodney, I am not sure if I am reading your email entirely correctly, but I think so... you're trying to figure out things like offsets so the Pickle runtime can re-build arbitrary data structures. When we were doing some concurrent programming in my group about ten years ago, we were using a user-level threading system (very similar but not identical to the old user-level threads in M3) and we needed to figure out the location of the stack pointer in a C jmp_buf. We just wrote a program to do it... Could you do that? Write some arbitrary data whose bit pattern you know to a field, cast it to char * (or some such), and search for the bit pattern? Do it over and over with random data, and there you go... Mika "Rodney M. Bates" writes: >The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >etc. only works for getting object layouts as on the machine executing >the code, which is all that is needed when writing a pickle. > >When reading, Pickle code needs to know the layouts of a type both as >it is on the reading machine and as it was on the machine that wrote >the pickle. The type description that the compiler generates is >excerpted and contains no field displacements, just lists of field >types (which are either recursive type descriptions or builtin types). >So it is independent of word sizes, etc. > >Pickles regenerates the displacements using the few target machine >characteristics in a RTPacking.T It traverses a type description and >simultaneously computes two sets of field displacements, both as they >are on the reading machine and on the writing machine. For the latter, >the value of RTPacking.T is (after a compact bit encoding) stored in the >header of the pickle file. For the former, it's gotten by techniques like >using BITSIZE. This is actually all done in RTTipe, part of m3core, and >called by Pickle code. > >This is very fragile. RTTipe has to duplicate the compiler's layout >behavior. There is no shared code. Making it common would involve >quite a bit of rework, as the two use substantially different data >structure and code organization. It will be obvious what kind of bit >damage could occur if the two algorithms didn't agree. > >This is why I am obsessing over LAZYALIGN. I have been comparing the >field displacement computations in RTTipe and in the compiler. The >former is oblivious to LAZYALIGN. > >Note that all this is required even without any packing of small fields >within words. E.G., a record with two INTEGER fields, pickled on a >32-bit machine and unpickled on a 64. > >Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I would >> have thought all packing is done on word-sized units anyway. Each side >> of the connection can check BITSIZE(LONGINT) to figure out what to do >> presumably no differently from the way INTEGER is communicated between >> 32-bit and 64-bit machines. Am I missing something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 >> >> >> > >-- >------------------------------------------------------------- >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 darko at darko.org Sat Feb 16 00:41:51 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:41:51 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B60D6E.8080704@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> <47B60D6E.8080704@wichita.edu> Message-ID: <385E6BF4-B476-4060-9EAD-DE1DCC74A2D9@darko.org> It's turned on at the platform level only. The result is that packed structures are packed as tightly as possible. On 16/02/2008, at 9:08 AM, Rodney M. Bates wrote: > So how is lazy alignment invoked for these types? In my grepping > and reading > in the compiler, I saw internal lazy alignment booleans turned on only > by the pragma. > > Darko wrote: >> The alignment rules are correctly associated with a type. I think >> the pragma can be removed. There are no pickles anywhere of these >> types. > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Sat Feb 16 00:51:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:51:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 10:34:47 +1100." <25955172-E857-4B24-8D51-3701C7353687@darko.org> Message-ID: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Darko writes: >I'm sticking to my view about lexical arbitrariness, but on that >basis, I'd really like to see an alternate syntax for M3, one that >looks almost exactly like C, but roughly keeps the existing statement >form. I think it would make the language much more palatable to C >programmers and the like and would remove what is a silly barrier to >broader adaption. We could call the syntax 'Modula-C'. This is getting a bit silly, and I apologize to everyone reading this about wasting their time, but I just have to show you the following file. It is a header file from the original sources of "sh" (this copy is from 4.3 TAHOE UNIX, but of course the code is much older than that). After that, blok.c, an example of "Bournegol" in use. So, you want the opposite, huh? Mika /* mac.h 4.3 87/10/26 */ # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #define LOCAL static #define PROC extern #define TYPE typedef #define STRUCT TYPE struct #define UNION TYPE union #define REG register #define IF if( #define THEN ){ #define ELSE } else { #define ELIF } else if ( #define FI ;} #define BEGIN { #define END } #define SWITCH switch( #define IN ){ #define ENDSW } #define FOR for( #define WHILE while( #define DO ){ #define OD ;} #define REP do{ #define PER }while( #undef DONE #define DONE ); #define LOOP for(;;){ #define POOL } #define SKIP ; #define DIV / #define REM % #define NEQ ^ #define ANDF && #define ORF || #define TRUE (-1) #define FALSE 0 #define LOBYTE 0377 #define STRIP 0177 #define QUOTE 0200 #define EOF 0 #define NL '\n' #define SP ' ' #define LQ '`' #define RQ '\'' #define MINUS '-' #define COLON ':' #ifndef lint static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; #endif # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #include "defs.h" /* * storage allocator * (circular first fit strategy) */ #define BUSY 01 #define busy(x) (Rcheat((x)->word)&BUSY) POS brkincr=BRKINCR; BLKPTR blokp; /*current search pointer*/ BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ ADDRESS alloc(nbytes) POS nbytes; { REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); LOOP INT c=0; REG BLKPTR p = blokp; REG BLKPTR q; REP IF !busy(p) THEN WHILE !busy(q = p->word) DO p->word = q->word OD IF ADR(q)-ADR(p) >= rbytes THEN blokp = BLK(ADR(p)+rbytes); IF q > blokp THEN blokp->word = p->word; FI p->word=BLK(Rcheat(blokp)|BUSY); return(ADR(p+1)); FI FI q = p; p = BLK(Rcheat(p->word)&~BUSY); PER p>q ORF (c++)==0 DONE addblok(rbytes); POOL } VOID addblok(reqd) POS reqd; { IF stakbas!=staktop THEN REG STKPTR rndstak; REG BLKPTR blokstak; pushstak(0); rndstak=round(staktop,BYTESPERWORD); blokstak=BLK(stakbas)-1; blokstak->word=stakbsy; stakbsy=blokstak; bloktop->word=BLK(Rcheat(rndstak)|BUSY); bloktop=BLK(rndstak); FI reqd += brkincr; reqd &= ~(brkincr-1); blokp=bloktop; bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); bloktop->word=BLK(ADR(end)+1); BEGIN REG STKPTR stakadr=STK(bloktop+2); staktop=movstr(stakbot,stakadr); stakbas=stakbot=stakadr; END } VOID free(ap) BLKPTR ap; { REG BLKPTR p; IF (p=ap) ANDF pword) &= ~BUSY; FI } #ifdef DEBUG chkbptr(ptr) BLKPTR ptr; { INT exf=0; REG BLKPTR p = end; REG BLKPTR q; INT us=0, un=0; LOOP q = Rcheat(p->word)&~BUSY; IF p==ptr THEN exf++ FI IF qbloktop THEN abort(3) FI IF p==bloktop THEN break FI IF busy(p) THEN us += q-p; ELSE un += q-p; FI IF p>=q THEN abort(4) FI p=q; POOL IF exf==0 THEN abort(1) FI prn(un); prc(SP); prn(us); prc(NL); } #endif From mika at async.caltech.edu Sat Feb 16 00:56:00 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:56:00 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Fri, 15 Feb 2008 18:17:41 EST." <20080215231741.GA4216@topoi.pooq.com> Message-ID: <200802152356.m1FNu0F3034075@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: >> >> What your video game developer friend needs is to do exercise #12 >> in section 2.3.5 in Knuth. (There are references to three existing >> solutions in the answer key.) > >Is that the one one completely concurrent garbage collection? Right, I think that's what Tony was (indirectly) referring to, as well. The publication dates on the three solutions range from 1975 to 1978... > >Unfortunately, he wants to write video games, not implement programming >languages. But ... I think he's tempted. > >I still feel I have to warn him of the time I wanted to write an >applocation and got side-tracked into writing the language in which the >application would be easy to write. I never got back to the >application. I don't even remember what it was. That was in the >1960's. I'm still stuck on languages. And, if you ask me, languages are still stuck! > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:18:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:18:30 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B61505.5080708@wichita.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <47B61505.5080708@wichita.edu> Message-ID: <20080216001830.GB4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 04:41:09PM -0600, Rodney M. Bates wrote: > I view this as more significant than it would first appear. More > important than readability is that delimiters with several letters > in all caps are more PROMINENT. This makes it quicker seeing the > overall structure of a piece of code before looking at the deeper > details such as which variable is being manipulated. > > Up to now, every person I have discussed it with who has spent enough > time coding with this style of delimiters to get over their initial > aversion has agreed the prominence of all caps makes the code structure > easier to see quickly. Even Ada programmers who had significant prior > experience in Modula-2 have preferred all caps in Ada (Ada is case- > insensitive, so you can do it as you please.) > > As for readability, I recall seeing research some years back that > showed all caps are less readable than lower case, that is, people > read all caps slower and/or with less accuracy. For the delimiters, > prominence is more important, especially since their vocabulary is > far smaller than that of identifiers and doesn't change from program > to program. As long as you don't have both else and elsf as keywords in the same language! It works find in lower-case but is hopeless in upper. > As for esthetics, speaking for myself, after many years, I still think > all caps reserved words are uglier than mud fences, but I happily accept > that as the cost of easier scanning of code. > > It would be nice we had a standard character code that could handle > lower case, bold face, as in the Algol 60 "publication language". > That would be prominent and look great too. Really, there should be nothing preventing us from writing editors that display all-upper-case words as red lower-case words, and m3-to-ps converters that print them as bold-face lower-case. -- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:25:15 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:25:15 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <25955172-E857-4B24-8D51-3701C7353687@darko.org> <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <20080216002515.GC4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:51:43PM -0800, Mika Nystrom wrote: > Darko writes: > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? Yeah. Steve Bourne did an Algol 68 variant in Cambridge before he went to Bell Labs. He did his bit here to make C look more like Algol 68C. Except A68 allows things to be a lot more terse than here. I think A68 had the right idea about syntax. Except that it was horrible to parse. -- hendrik From darko at darko.org Sat Feb 16 08:30:29 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 18:30:29 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> I'm not sure what you're getting at or if I'm missing something witty. I've said the form of the keywords makes little or no difference in my opinion. In my mail you quote I say there should be a C like syntax for M3 as well as the existing one. I wasn't being sarcastic. It's a matter of taste. I write in both all the time and it doesn't have any impact on me, I go almost entirely by indentation, which I think is very important. The indentation is pretty awful in code you posted but it could me my mailer. On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > Darko writes: >> I'm sticking to my view about lexical arbitrariness, but on that >> basis, I'd really like to see an alternate syntax for M3, one that >> looks almost exactly like C, but roughly keeps the existing statement >> form. I think it would make the language much more palatable to C >> programmers and the like and would remove what is a silly barrier to >> broader adaption. We could call the syntax 'Modula-C'. > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? > > Mika > > > /* mac.h 4.3 87/10/26 */ > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #define LOCAL static > #define PROC extern > #define TYPE typedef > #define STRUCT TYPE struct > #define UNION TYPE union > #define REG register > > #define IF if( > #define THEN ){ > #define ELSE } else { > #define ELIF } else if ( > #define FI ;} > > #define BEGIN { > #define END } > #define SWITCH switch( > #define IN ){ > #define ENDSW } > #define FOR for( > #define WHILE while( > #define DO ){ > #define OD ;} > #define REP do{ > #define PER }while( > #undef DONE > #define DONE ); > #define LOOP for(;;){ > #define POOL } > > > #define SKIP ; > #define DIV / > #define REM % > #define NEQ ^ > #define ANDF && > #define ORF || > > #define TRUE (-1) > #define FALSE 0 > #define LOBYTE 0377 > #define STRIP 0177 > #define QUOTE 0200 > > #define EOF 0 > #define NL '\n' > #define SP ' ' > #define LQ '`' > #define RQ '\'' > #define MINUS '-' > #define COLON ':' > > > > #ifndef lint > static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; > #endif > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #include "defs.h" > > > /* > * storage allocator > * (circular first fit strategy) > */ > > #define BUSY 01 > #define busy(x) (Rcheat((x)->word)&BUSY) > > POS brkincr=BRKINCR; > BLKPTR blokp; /*current search pointer*/ > BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ > > > > ADDRESS alloc(nbytes) > POS nbytes; > { > REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); > > LOOP INT c=0; > REG BLKPTR p = blokp; > REG BLKPTR q; > REP IF !busy(p) > THEN WHILE !busy(q = p->word) DO p->word = q->word OD > IF ADR(q)-ADR(p) >= rbytes > THEN blokp = BLK(ADR(p)+rbytes); > IF q > blokp > THEN blokp->word = p->word; > FI > p->word=BLK(Rcheat(blokp)|BUSY); > return(ADR(p+1)); > FI > FI > q = p; p = BLK(Rcheat(p->word)&~BUSY); > PER p>q ORF (c++)==0 DONE > addblok(rbytes); > POOL > } > > VOID addblok(reqd) > POS reqd; > { > IF stakbas!=staktop > THEN REG STKPTR rndstak; > REG BLKPTR blokstak; > > pushstak(0); > rndstak=round(staktop,BYTESPERWORD); > blokstak=BLK(stakbas)-1; > blokstak->word=stakbsy; stakbsy=blokstak; > bloktop->word=BLK(Rcheat(rndstak)|BUSY); > bloktop=BLK(rndstak); > FI > reqd += brkincr; reqd &= ~(brkincr-1); > blokp=bloktop; > bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); > bloktop->word=BLK(ADR(end)+1); > BEGIN > REG STKPTR stakadr=STK(bloktop+2); > staktop=movstr(stakbot,stakadr); > stakbas=stakbot=stakadr; > END > } > > VOID free(ap) > BLKPTR ap; > { > REG BLKPTR p; > > IF (p=ap) ANDF p THEN Lcheat((--p)->word) &= ~BUSY; > FI > } > > #ifdef DEBUG > chkbptr(ptr) > BLKPTR ptr; > { > INT exf=0; > REG BLKPTR p = end; > REG BLKPTR q; > INT us=0, un=0; > > LOOP > q = Rcheat(p->word)&~BUSY; > IF p==ptr THEN exf++ FI > IF qbloktop THEN abort(3) FI > IF p==bloktop THEN break FI > IF busy(p) > THEN us += q-p; > ELSE un += q-p; > FI > IF p>=q THEN abort(4) FI > p=q; > POOL > IF exf==0 THEN abort(1) FI > prn(un); prc(SP); prn(us); prc(NL); > } > #endif From jayk123 at hotmail.com Sat Feb 16 08:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 07:34:27 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: > The indentation is pretty awful in code you posted but > it could me my mailer. Yep..it was eight space tabs at every level for me. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Feb 16 10:42:28 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 01:42:28 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 18:30:29 +1100." <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> "If Steve Bourne could turn C into Algol using cpp, I'm sure you can figure out how to turn Algol[Modula] back into C using <...>"... If you think it would help acceptance of Modula-3, I don't see why not? I copied the code exactly the way it came off the old half-inch tape from Berkeley. Darko writes: >I'm not sure what you're getting at or if I'm missing something witty. >I've said the form of the keywords makes little or no difference in my >opinion. In my mail you quote I say there should be a C like syntax >for M3 as well as the existing one. I wasn't being sarcastic. It's a >matter of taste. I write in both all the time and it doesn't have any >impact on me, I go almost entirely by indentation, which I think is >very important. The indentation is pretty awful in code you posted but >it could me my mailer. > >On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: ... From darko at darko.org Sat Feb 16 11:10:40 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 21:10:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> References: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> Message-ID: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> If you like the idea, maybe you'd like join me in working out what such a syntax would look like? Note that I want to keep the structure the same, so no assignments in expressions, for example. Also, would C programmers revolt at not having post and pre increment, also inside expressions (as statements would be ok)? Requiring some sort of EVAL statement? I guess the big question is whether removing these things would make the whole idea unacceptable to the target audience. Does the Algol syntax serve a purpose in making it clear that it isn't C? On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > > "If Steve Bourne could turn C into Algol using cpp, I'm sure you > can figure out how to turn Algol[Modula] back into C using <...>"... > > If you think it would help acceptance of Modula-3, I don't see why > not? > > I copied the code exactly the way it came off the old half-inch > tape from Berkeley. > > Darko writes: >> I'm not sure what you're getting at or if I'm missing something >> witty. >> I've said the form of the keywords makes little or no difference in >> my >> opinion. In my mail you quote I say there should be a C like syntax >> for M3 as well as the existing one. I wasn't being sarcastic. It's a >> matter of taste. I write in both all the time and it doesn't have any >> impact on me, I go almost entirely by indentation, which I think is >> very important. The indentation is pretty awful in code you posted >> but >> it could me my mailer. >> >> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > ... From jayk123 at hotmail.com Sat Feb 16 20:30:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:30:01 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*) Without those lines commented out, only ever one file gets compiled. The process create for the second cm3cg fails (but not for the first as). Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything. Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle? I figured this out with strace. The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly. For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 20:37:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:37:46 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 21:31:53 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 20:31:53 +0000 Subject: [M3devel] FW: NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: seems to have gotten truncated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Feb 17 06:43:38 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 21:43:38 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sat, 16 Feb 2008 21:10:40 +1100." <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> Message-ID: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Well I used to be mostly a C programmer but I long since weaned myself off that syntax :) Your point of the post- and pre-increment might be a bit difficult for C programmers to stomach, but... well it is probably hard to tell what programmers will hate and what they will love. Wouldn't a way to go about it be to take the Modula-3 BNF and modify the rules as needed? Would you like to be able to convert back and forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case all the keywords, convert the braces appropriately (a bit tricky since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO BEGIN END, so braces map only to the ENDs, not BEGINs (for the most part)). Type "attributes"(is that the right word?) are also an area where Modula-3 is significantly different from the C family. In C, you write int *a, *b, c; we have REF INTEGER a, b; INTEGER c; And arrays? VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; I prefer Algol syntax myself but I could definitely see that there might be people who would prefer a syntax mapped to C. One might be able to sneak Modula-3 into places where it wouldn't otherwise be used... Would it be possible to make "m3c" close enough in syntax that some simple C header files could be processed? Am I just being ridiculous now? A compiler that can process both C and Modula-3 in the same file? Python, by the way, provides some interesting hooks for C programs to interact with the Python garbage collector. Something similar could be done here. (But there is far less reason to write C code to plug into M3 than there is to write it to plug into Python.) Mika Darko writes: >If you like the idea, maybe you'd like join me in working out what >such a syntax would look like? Note that I want to keep the structure >the same, so no assignments in expressions, for example. Also, would C >programmers revolt at not having post and pre increment, also inside >expressions (as statements would be ok)? Requiring some sort of EVAL >statement? I guess the big question is whether removing these things >would make the whole idea unacceptable to the target audience. Does >the Algol syntax serve a purpose in making it clear that it isn't C? > > >On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > >> >> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >> can figure out how to turn Algol[Modula] back into C using <...>"... >> >> If you think it would help acceptance of Modula-3, I don't see why >> not? >> >> I copied the code exactly the way it came off the old half-inch >> tape from Berkeley. >> >> Darko writes: >>> I'm not sure what you're getting at or if I'm missing something >>> witty. >>> I've said the form of the keywords makes little or no difference in >>> my >>> opinion. In my mail you quote I say there should be a C like syntax >>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>> matter of taste. I write in both all the time and it doesn't have any >>> impact on me, I go almost entirely by indentation, which I think is >>> very important. The indentation is pretty awful in code you posted >>> but >>> it could me my mailer. >>> >>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >> ... From hendrik at topoi.pooq.com Sun Feb 17 07:29:03 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 01:29:03 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217062903.GA24856@topoi.pooq.com> On Sat, Feb 16, 2008 at 09:43:38PM -0800, Mika Nystrom wrote: > > > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; The declarator syntax in C was a mistake. Let's not perpetuate it. -- hendrik From jayk123 at hotmail.com Sun Feb 17 09:47:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 08:47:52 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Nevermind, of course, I should have known, even though I'm working on fixing the stat struct (probably to blame for files always being out of date) and thought I might have it right, I should have known, I have it too small and the next variable is getting overwritten, causing us to close(0).. If I put in arbitrary large padding at the end, it grows enough to cover up the problem..now to get it right.. null_fd and the entire struct stat need not be globals, just the dev field...of course optimize that and I would have a stack corruption instead, not sure it would have been harder or easier to figure out..I should have started at the bottom of the system and gotten all the headers right in the first place....sigh. VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN null_done := TRUE; null_fd := Unix.open( M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, ADR(null_stat)); RTIO.PutText("2 null_fd is " & Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); and then close 0 here oops IF result # 0 THEN null_fd := -1 END From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 17 10:30:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 10:30:01 +0100 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Quoting Jay : > Nevermind, of course, I should have known, even though I'm working > on fixing the stat struct (probably to blame for files always being > out of date) and thought I might have it right, I should have known, > I have it too small and the next variable is getting overwritten, > causing us to close(0).. Yes, the C interfaces are the place where ports are most likely to be broken. There are no checks there; it's completely unsafe. I wonder if one could write a checker that compares the sizes of the most important structures in C and M3, but that would probably not be trivial. > If I put in arbitrary large padding at the end, it grows enough to > cover up the problem..now to get it right.. > null_fd and the entire struct stat need not be globals, just the dev > field...of course optimize that and I would have a stack corruption > instead, not sure it would have been harder or easier to figure > out..I should have started at the bottom of the system and gotten > all the headers right in the first place....sigh. Yes, it's always a good idea to get the base right at the start. On the other hand, you will usually return there during ant porting, regardless of your best efforts ;-) > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; > > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > null_done := TRUE; null_fd := Unix.open( > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > and then close 0 here oops IF result # 0 THEN null_fd := -1 END [Could you try to persuade your mailer to produce a readable text form besides HTML? If not it looks like that :-(] Anyway, as your previous posting asked about a change in general POSIX support files, I'd really advise you to try out such changes on at least one other platform (e.g. Linux), however innocuous they may seem. Thanks for all the work, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Feb 17 10:57:15 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 09:57:15 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Message-ID: No need for a change in platform-independent code now. My question was sort of "can anyone else try this out, I'm lazy". But I looked up the definition of dup/dup2 and decided Cygwin wasn't doing anything wrong, looked at the strace, saw we were closing 0, started some RTIO... and if IsDebuggerPresent, DebugBreak and finally realized of course what was happening. (the debugging options are really not good. I couldn't even see the globals in gdb, neither of the obvious names worked...I was doing a little debugging in cdb as well and found a crashing bug in it, very very very unusual) Writing a struct checker should actually be pretty easy. The trick is probably mainly to limit the dependencies so it can work when much of the system is broken, or to use a cross strategy if possible..it helps that NT386 supports two sort of platforms/targets/configurations, so you can cross with a smaller context switch. :) I'm not sure how to get field offsets in Modula-3 but if you get as far as having the compiler working, it can generate C with assertions as to sizes and offsets. The compiler's dependency on stat is "the problem". Again I like that idea of wrapping C in C, to expose a portable interface.Of course, it's inefficient. The direct exporting of C interfaces, when they are /correct/ is pretty efficient. NT386GNU should be just about "self hosting" now -- able to build a "min" distribution and then "upgrade". Small hacks in pylib.py needed that might break Win32, no big deal, it's "just the scripts". :) Next steps will be: a) consider changing the "naming conventions" it's still foo.lib and not foo.a, foo.dll and not foo.so. b) see if X Windows works (stuff builds) c) the small set and bitmap bugs (running the tests!) I do have one more commit to enable stuff, a small one, where the Slash is determine at runtime in slightly more code. SL is already determined at runtime, but M3Path maps naming convensions (foo.lib vs. libfoo.a, foo.dll vs. foo.so) to also determine slashes. It might even work if they were escaped, but what I have is a good solution. (if I figure I can ramble here, since I'm on topic. :) ) - Jay > Date: Sun, 17 Feb 2008 10:30:01 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] NT386GNU status/fishing for guesses..> > Quoting Jay :> > > Nevermind, of course, I should have known, even though I'm working > > on fixing the stat struct (probably to blame for files always being > > out of date) and thought I might have it right, I should have known, > > I have it too small and the next variable is getting overwritten, > > causing us to close(0)..> > Yes, the C interfaces are the place where ports are most likely to> be broken. There are no checks there; it's completely unsafe.> I wonder if one could write a checker that compares the sizes of> the most important structures in C and M3, but that would probably> not be trivial.> > > If I put in arbitrary large padding at the end, it grows enough to > > cover up the problem..now to get it right..> > null_fd and the entire struct stat need not be globals, just the dev > > field...of course optimize that and I would have a stack corruption > > instead, not sure it would have been harder or easier to figure > > out..I should have started at the bottom of the system and gotten > > all the headers right in the first place....sigh.> > Yes, it's always a good idea to get the base right at the start.> On the other hand, you will usually return there during ant porting,> regardless of your best efforts ;-)> > > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER;> >> > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > > null_done := TRUE; null_fd := Unix.open( > > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > > and then close 0 here oops IF result # 0 THEN null_fd := -1 END> > [Could you try to persuade your mailer to produce a readable text> form besides HTML? If not it looks like that :-(]> > Anyway, as your previous posting asked about a change in general POSIX> support files, I'd really advise you to try out such changes on at> least one other platform (e.g. Linux), however innocuous they may seem.> > Thanks for all the work,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 17 14:16:59 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 08:16:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> Message-ID: <20080217131659.GA25696@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > [...many other good comments deleted...] > > > >Multiple inheritance was left out of the language after long > >discussions because it was not really understood at that time. > >It may be that things have changed in this respect, but I still > >don't think it is. > > Multiple inheritance is fine so long as it encodes only type, but > *not* if it encodes representation as well. Witness single > inheritance for classes in Java, versus multiple inheritance for > interfaces in Java. That seems to be the general consensus these days. Multiple inheritance could still work under the constraint that no two ancestors provided different representations for any feature. I'd count separate definitions of a virtual function as different even if their code happens to be textually identical. Then an interface (like in Java) would be nothing but a class that has no representation. Then to build a class you could combine little chunks of representation, much as a linker combines little pieces of program. and multiple MODULEs can implement parts of the same INTERFACE. And by combining chunks chunks differently you could build classes with different behaviour. This would make more code-sharing is feasible, without a crisis in semantics. I could consider adding the following clause, because I think it would help modularity (though I'm not sure it's necessary): But if both ancestors have the same defined representation but they are ultimately inherited from the same definition, I'd count them as the same (though I could be argued out of this clause). Actully, I suppose this might be necessary because all objects inherit representation from OBJECT, and a general rule might be better than a special case for OBJECT. -- hendrik From wagner at elegosoft.com Sun Feb 17 14:31:38 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 14:31:38 +0100 Subject: [M3devel] Integration of package-local tests Message-ID: <20080217143138.izfhuwm2yosw0g4w@mail.elegosoft.com> As some of you may have noticed, the regression test scope is increasing steadily though slowly. During recent days I tried to integrate the existing tests that are local to some packages. It's working this way: During a complete package build run with ./scripts/do-cm3-all.sh -report build all pacakges are compiled and the results reported on the web server (see http://www.opencm3.net/logs/package-status.html). For an easy overview, packages that compile OK are coloured green, packages with errors are red, and those unsupported on a certain platform are marked yellow. Recently a fourth column has been added which reports the results of tests if they are present. Tests are assumed if in the package root a sub directory test or tests exists, and if beneath that src/m3makefile is found. The fourth column will be yellow if this is not the case. If tests are present, they are compiled and (probably) run with cm3 -build -override -DROOT=$ROOT -DRUN A sample tests/src/m3makefile from package arithmetic looks like this: import("libm3") import("tempfiles") import("arithmetic") implementation("TestWordEx") implementation("TestBits") %[more test sources omitted] implementation("TestFunctional") Module("Test") program("test") if defined("RUN") r = q_exec( "." & SL & "test" ) write( CR, "program returned ", r, CR ) end The last four lines will run the compiled test executable. Of course, more complex setups are possible there. The test result column will be red if the tests do not compile or another fatal error is detected, orange, if something is output to stderr, and green in all other cases. At least for the actual test candidate an appropriate override should be defined like this: override("arithmetic", PACKAGE_DIR & SL & ".." & SL & "..") As usual, this should be done in the src/m3overrides file. To give a slightly more complex example, the tests for patternmatching are performed thus: if defined("RUN") r = q_exec( "." & SL & "test-regex -unix < .." & SL & "tests.input" ) write( CR, "program returned ", r, CR ) r = q_exec( "." & SL & "test-regex -unix < .." & SL & "testsdiffer.input" ) write( CR, "program returned ", r, CR ) end Here, two test runs are made with different input files. I'd like to encourage all contributors to adapt or extend their packages accordingly, so that more things can be automatically validated every night on miscellaneous platforms. Of course it would also be great if the encountered errors get fixed :-) Thanks for your attention and cooperation, Olaf PS: I'll attach one current package report file for those too lazy to follow the links ;-) PPS: Of course you can run the tests and generate the reports locally, too. During development I've used something like HTML_REPORT=/var/tmp/cm3-pkg-report-FreeBSD4-2008-02-17.html \ time ./scripts/do-cm3-all.sh -report build 2>&1 | tee plog to generate a complete report with a fixed name and log all actions in plog. PPPS: The actual implementation of report generation is in scripts/pkgmap.sh. So you can use -report with almost all build scripts. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sun Feb 17 18:39:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 18:39:07 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> It's now more than two weeks since I asked for participants, and none but the elego tests have shown up in the tinderbox since then. So I think it may be time for a reminder :-) I don't want to hurry anyone, but if anything does not work as expected or described or someone needs help getting tinderbox reports transfered, don't hesitate to contact me. I'd really love to see more platforms than FreeBSD and Linux and the occasional DARWIN tested on a regular basis. Olaf PS: No need to apologize for anyone who maybe hasn't found the time yet to setup the test runs. I really understand that there are many more important matters. Quoting Olaf Wagner : > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression testing >> would help and should be introduced. Tests should be run daily/nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox > /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Sun Feb 17 19:04:44 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 17 Feb 2008 12:04:44 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> References: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Message-ID: <47B8773C.50803@wichita.edu> Well, in the case of pickles, there is not currently any known bit pattern to look for. Everything is either user's data, which must be allowed to be arbitrary, or pickle protocol stuff, which is already written in target-independent ways, so it wouldn't reveal anything. Adding a record of carefully designed, known type and content to the pickle header would work for general machine characteristics, but it's easier just to add a field to RTPacking values, which are binary-encoded in 32 bits in the existing header, with bits to spare. Similarly, for lazy aligned objects (where each type can be different), it's easiest just to add a bit type descriptions, which are also binary encoded. Mika Nystrom wrote: > Hi Rodney, > > I am not sure if I am reading your email entirely correctly, but I > think so... you're trying to figure out things like offsets so the > Pickle runtime can re-build arbitrary data structures. > > When we were doing some concurrent programming in my group about ten > years ago, we were using a user-level threading system (very similar > but not identical to the old user-level threads in M3) and we needed > to figure out the location of the stack pointer in a C jmp_buf. > > We just wrote a program to do it... > > Could you do that? Write some arbitrary data whose bit pattern > you know to a field, cast it to char * (or some such), and search > for the bit pattern? Do it over and over with random data, and there > you go... > > Mika > -- ------------------------------------------------------------- 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 Sun Feb 17 19:03:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 19:03:17 +0100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> I'd rather not go this way and change the complete syntax and convert to and fro between the two. If we really want to do that, I'd rather have it as something like a compatible extension (as far as possible). What about changing only the keywords from uppercase to lowercase and using {} instead of BEGIN END? I'm not sure if that would satisfy the C-adherents, and I'm also not sure if it would introduce syntactic ambiguities, as {} are also used for sets. I'd like to keep the changes to the syntactical structure minimal (upper- and lowercase is only lexical matter after all). The abstract syntax should be kept as it is. If something like this would be possible, I'd vote for supporting both syntaxes in one compiler and turn on the C-style by a comment or automatically by recognizing the first word of a module. I'd not support mixing of styles within one module. Olaf PS: I'm not really suggesting we do this now, I just wanted to comment on the possibility of doing something like this. Anyway it will depend on somebody who provides appropriate patches and updates the language specification etc. Quoting Mika Nystrom : > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; > > And arrays? > > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; > > ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; > > I prefer Algol syntax myself but I could definitely see that there > might be people who would prefer a syntax mapped to C. One might > be able to sneak Modula-3 into places where it wouldn't otherwise > be used... > > Would it be possible to make "m3c" close enough in syntax that some > simple C header files could be processed? Am I just being ridiculous > now? A compiler that can process both C and Modula-3 in the same > file? > > Python, by the way, provides some interesting hooks for C programs > to interact with the Python garbage collector. Something similar > could be done here. (But there is far less reason to write C code > to plug into M3 than there is to write it to plug into Python.) > > Mika > > > Darko writes: >> If you like the idea, maybe you'd like join me in working out what >> such a syntax would look like? Note that I want to keep the structure >> the same, so no assignments in expressions, for example. Also, would C >> programmers revolt at not having post and pre increment, also inside >> expressions (as statements would be ok)? Requiring some sort of EVAL >> statement? I guess the big question is whether removing these things >> would make the whole idea unacceptable to the target audience. Does >> the Algol syntax serve a purpose in making it clear that it isn't C? >> >> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >> >>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>> can figure out how to turn Algol[Modula] back into C using <...>"... >>> >>> If you think it would help acceptance of Modula-3, I don't see why >>> not? >>> >>> I copied the code exactly the way it came off the old half-inch >>> tape from Berkeley. >>> >>> Darko writes: >>>> I'm not sure what you're getting at or if I'm missing something >>>> witty. >>>> I've said the form of the keywords makes little or no difference in >>>> my >>>> opinion. In my mail you quote I say there should be a C like syntax >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>>> matter of taste. I write in both all the time and it doesn't have any >>>> impact on me, I go almost entirely by indentation, which I think is >>>> very important. The indentation is pretty awful in code you posted >>>> but >>>> it could me my mailer. >>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>> ... > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Feb 17 19:11:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 13:11:39 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Not to rain on this parade, but I hate the idea of Swiss-Army-knife programs that do a multitude of tasks. Better to have a program do one thing well (and correctly) than many things badly (incorrectly). So the notion of one compiler handling two syntaxes does not sit well with me. Why not just a preprocessor from C-like syntax, which observes Modula-3 typing and semantics, into regular Modula-3? But, I echo Olaf's point -- there are way more important things to be worrying about than the color of the ceiling tiles, or in this case syntactic sugar. On Feb 17, 2008, at 1:03 PM, Olaf Wagner wrote: > I'd rather not go this way and change the complete syntax and > convert to and fro between the two. If we really want to do that, > I'd rather have it as something like a compatible extension (as far > as possible). > > What about changing only the keywords from uppercase to lowercase > and using {} instead of BEGIN END? I'm not sure if that would > satisfy the C-adherents, and I'm also not sure if it would > introduce syntactic ambiguities, as {} are also used for sets. > I'd like to keep the changes to the syntactical structure minimal > (upper- and lowercase is only lexical matter after all). The abstract > syntax should be kept as it is. > > If something like this would be possible, I'd vote for supporting > both syntaxes in one compiler and turn on the C-style by a comment > or automatically by recognizing the first word of a module. I'd not > support mixing of styles within one module. > > Olaf > > PS: I'm not really suggesting we do this now, I just wanted to comment > on the possibility of doing something like this. Anyway it will > depend on somebody who provides appropriate patches and updates > the language specification etc. > > Quoting Mika Nystrom : > >> Well I used to be mostly a C programmer but I long since weaned >> myself off that syntax :) >> >> Your point of the post- and pre-increment might be a bit difficult >> for C programmers to stomach, but... well it is probably hard to >> tell what programmers will hate and what they will love. >> >> Wouldn't a way to go about it be to take the Modula-3 BNF and modify >> the rules as needed? Would you like to be able to convert back and >> forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case >> all the keywords, convert the braces appropriately (a bit tricky >> since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO >> BEGIN END, so braces map only to the ENDs, not BEGINs (for the most >> part)). >> >> Type "attributes"(is that the right word?) are also an area where >> Modula-3 is significantly different from the C family. In C, you >> write >> >> int *a, *b, c; >> >> we have >> >> REF INTEGER a, b; >> INTEGER c; >> >> And arrays? >> >> VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF >> ARecord; >> >> ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; >> >> I prefer Algol syntax myself but I could definitely see that there >> might be people who would prefer a syntax mapped to C. One might >> be able to sneak Modula-3 into places where it wouldn't otherwise >> be used... >> >> Would it be possible to make "m3c" close enough in syntax that some >> simple C header files could be processed? Am I just being ridiculous >> now? A compiler that can process both C and Modula-3 in the same >> file? >> >> Python, by the way, provides some interesting hooks for C programs >> to interact with the Python garbage collector. Something similar >> could be done here. (But there is far less reason to write C code >> to plug into M3 than there is to write it to plug into Python.) >> >> Mika >> >> >> Darko writes: >>> If you like the idea, maybe you'd like join me in working out what >>> such a syntax would look like? Note that I want to keep the >>> structure >>> the same, so no assignments in expressions, for example. Also, >>> would C >>> programmers revolt at not having post and pre increment, also inside >>> expressions (as statements would be ok)? Requiring some sort of EVAL >>> statement? I guess the big question is whether removing these things >>> would make the whole idea unacceptable to the target audience. Does >>> the Algol syntax serve a purpose in making it clear that it isn't C? >>> >>> >>> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >>> >>>> >>>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>>> can figure out how to turn Algol[Modula] back into C using >>>> <...>"... >>>> >>>> If you think it would help acceptance of Modula-3, I don't see why >>>> not? >>>> >>>> I copied the code exactly the way it came off the old half-inch >>>> tape from Berkeley. >>>> >>>> Darko writes: >>>>> I'm not sure what you're getting at or if I'm missing something >>>>> witty. >>>>> I've said the form of the keywords makes little or no >>>>> difference in >>>>> my >>>>> opinion. In my mail you quote I say there should be a C like >>>>> syntax >>>>> for M3 as well as the existing one. I wasn't being sarcastic. >>>>> It's a >>>>> matter of taste. I write in both all the time and it doesn't >>>>> have any >>>>> impact on me, I go almost entirely by indentation, which I >>>>> think is >>>>> very important. The indentation is pretty awful in code you posted >>>>> but >>>>> it could me my mailer. >>>>> >>>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>>> ... >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Sun Feb 17 19:58:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 13:58:41 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: <20080217185841.GA27354@topoi.pooq.com> On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. Even with a preprocessor from C-style syntax to Modula 3, there would have to be some mechanism inserted into the Modula 3 compiler to recognise the original line numbers for error messages and debuggers and the like. Doing it this way might also make it possible to unify the Eiffel and Modula 3 communities ... though tere are possible better ways to accomplish this. I've always thought there's a lot of duplication of effort in their run-time systems. -- hendrik From lemming at henning-thielemann.de Sun Feb 17 21:27:47 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:27:47 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: On Sun, 17 Feb 2008, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. I see no need for Modula-3 with C syntax. I thought Java was created for this purpose. I collected a long list of C flaws, many of them are due to C syntax. From lemming at henning-thielemann.de Sun Feb 17 21:39:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:39:04 +0100 (MET) Subject: [M3devel] multiple inheritance In-Reply-To: <20080217131659.GA25696@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> <20080217131659.GA25696@topoi.pooq.com> Message-ID: On Sun, 17 Feb 2008 hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > > > [...many other good comments deleted...] > > > > > > >Multiple inheritance was left out of the language after long > > >discussions because it was not really understood at that time. > > >It may be that things have changed in this respect, but I still > > >don't think it is. Without knowing details I have heard that Eiffel has a satisfying implementation of multiple inheritance. However, since programming in Haskell I'm no longer missing traditional object oriented typing at all. From mika at async.caltech.edu Sun Feb 17 22:30:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 13:30:50 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sun, 17 Feb 2008 13:58:41 EST." <20080217185841.GA27354@topoi.pooq.com> Message-ID: <200802172130.m1HLUoMd000557@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: >> Not to rain on this parade, but I hate the idea of Swiss-Army-knife >> programs that do a multitude of tasks. Better to have a program do >> one thing well (and correctly) than many things badly (incorrectly). >> So the notion of one compiler handling two syntaxes does not sit well >> with me. Why not just a preprocessor from C-like syntax, which >> observes Modula-3 typing and semantics, into regular Modula-3? But, >> I echo Olaf's point -- there are way more important things to be >> worrying about than the color of the ceiling tiles, or in this case >> syntactic sugar. > >Even with a preprocessor from C-style syntax to Modula 3, there would >have to be some mechanism inserted into the Modula 3 compiler to >recognise the original line numbers for error messages and debuggers and >the like. > >Doing it this way might also make it possible to unify the Eiffel and >Modula 3 communities ... though tere are possible better ways to >accomplish this. I've always thought there's a lot of duplication of >effort in their run-time systems. > >-- hendrik I agree entirely with Tony's comments. I think a preprocessor (two preprocessors M3-2-MC and MC-2-M3) would be the way to do it, and I really don't mind Algol syntax. But I can see the argument that it might really do something for "marketing". I believe the compiler already permits <* LINE *> pragmas?? I think I saw it in the caltech-parser? Also if you want to merge forces with another project, wouldn't a good way be to do as in Stallman's nightmares, and start by "selling" the compiler back ends to other languages? Mika From jayk123 at hotmail.com Mon Feb 18 05:03:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:03:23 +0000 Subject: [M3devel] instructions for how to bring up a working NT386GNU toolset today Message-ID: This email has whitespace at the start/end of most lines in an attempt to preserve its formating. I already had cm3cg, and it is slow to rebuild. These instructions omit building that, but it is just build and ship in m3-sys\m3cc. Building m3cc does require a fair bit of Cygwin installed. Including but not limited to gcc, binutils, sed, make, awk. copy \cm3\bin\cm3cg.exe C:\cm3-min-WIN32-NT386-5.1.8\bin rmdir /q/s \cm3 xcopy /fivery C:\cm3-min-WIN32-NT386-5.1.8 c:\cm3 Older than 5.1.8 will not work. Setup a cm3/NT386 build environment, for example: set CM3_GCC_BACKEND=no set CM3_INSTALL=c:\cm3 set CM3_OSTYPE=WIN32 set CM3_ROOT=c:\dev2\cm3.2 set CM3_TARGET=NT386 set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 Almost none of these are needed, as they are probed for quite successfully. However this is what I am testing right now. Make sure Cygwin link.exe is not in %PATH%. I just delete it. del \cygwin\bin\link.exe I do actually have Cygwin always on my path, so there might be hidden dependencies on that. type \AUTOEXEC.BAT set CVS_RSH=ssh PATH %SystemDrive%\cygwin\bin;%PATH% There are also presently problems with slashes, such that managing M3CONFIG manually is a good idea for now. cd /d %cm3_root%\scripts\python .\do-cm3-all.py realclean .\upgrade.py In another cmd window, setup a CM3/NT386GNU environment, for example: set CM3_GCC_BACKEND=yes set CM3_INSTALL=/cm3 set CM3_OSTYPE=POSIX set CM3_ROOT=/dev2/cm3.2 set CM3_TARGET=NT386 set M3CONFIG=/dev2/cm3.2/m3-sys/cminstall/src/config/NT386GNU set OMIT_GCC=yes Again, this is largely redundant, but ok. What is most important is that CM3_OSTYPE=POSIX or that Cygwin uname is in the path. (Work is needed to cleanup this area that I have muddied over the past few months, including teaching cm3 that forward slashes work on Win32, except that won't help bootstrapping from 5.1.8) Also NOTE that I have symlinks setup for these paths to be correct: ls -l / lrwxrwxrwx 1 Jay None 11 Feb 10 01:10 c -> /cygdrive/c lrwxrwxrwx 1 Jay None 6 Feb 10 21:39 cm3 -> /c/cm3 lrwxrwxrwx 1 Jay None 7 Feb 10 01:10 dev2 -> /c/dev2 /cygdrive is long and ugly. .\do-cm3-all.py realclean Back in the NT386 environment: Point at the NT386GNU configuration file: set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386GNU Build the minimum NT386GNU system using the NT386 host compiler: .\bootntgnu.py and then restore the configuration to "normal": set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 (Yeah yeah, to clean step should work here.) Back in the NT386GNU environment: .\install-cm3-compiler.py .\upgrade.py Done. Next step is to try make-dist.py. (It doesn't work.) Also note that do-cm3-std gets much further than these steps. But these are just to start and get your own "min" system. A crash in m3bundle needs investigation if is still happens. Lots of GUI stuff does build but I haven't tried running it yet. Also NOTE that the integrated backend should be viable for targeting the Cygwin runtime, and this will build MUCH faster. Of course, you must have current source for this to work. I have not yet run the tests, sorry Olaf. Anyone want to try this and report back how it goes? Please? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx From hosking at cs.purdue.edu Mon Feb 18 05:16:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 23:16:06 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> Message-ID: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Solaris does not have %s for date -- we need an alternative for that usage in tinderbox-build.sh. On Feb 17, 2008, at 12:39 PM, Olaf Wagner wrote: > It's now more than two weeks since I asked for participants, and > none but the elego tests have shown up in the tinderbox since then. > So I think it may be time for a reminder :-) > > I don't want to hurry anyone, but if anything does not work as > expected or described or someone needs help getting tinderbox > reports transfered, don't hesitate to contact me. I'd really love to > see more platforms than FreeBSD and Linux and the occasional DARWIN > tested on a regular basis. > > Olaf > > PS: No need to apologize for anyone who maybe hasn't found the time > yet > to setup the test runs. I really understand that there are many > more > important matters. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >>> o I think we have agreed on the fact that automatic regression >>> testing >>> would help and should be introduced. Tests should be run daily/ >>> nightly >>> on as many platforms as possible, and results should be collected >>> and made available via WWW (elego offers to host these >>> services, as >>> it does for CVS repositories and CM3 web access). >> >> As you've surely all seen in the Status section of >> >> http://modula3.elegosoft.com/cm3/ >> >> the Elego Tinderbox regression test framework for CM3 has now been >> working for about two weeks. Though it's still not as complete and >> stable as I'd like it to be, I think it is now the right time for >> others >> to join the test framework and run the prepared tests in regular >> intervals on their favourite platforms. The results can now be >> transfered >> to Elego via your ssh account you also use for repository commits. >> >> Currently the tests are running on a Debian Linux system and a >> FreeBSD 6 >> system at Elego, and now and then I'm starting a run on my MacOS X >> laptop. The latter is not ideal for this purpose though. >> >> I'm now looking for other who would be willing to setup nightly tests >> on their own servers. The following systems are of interest >> >> o PPC_DARWIN on MacOS X 10.4 or 10.5 >> o I386_DARWIN >> o SOLgnu on any Solaris version >> o SOLsun " >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten >> some variants?) >> o NT386* on Windows 2000/XP/Vista >> o NetBSD2_i386 >> o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) >> o PPC_LINUX (though this seems to be broken for some time) >> o ALPHA_OSF -- is anybody still using Alphas? >> >> I think the other targets are more or less unused, but would of >> course not >> object to test results for them. >> >> There's a short description by Kaspar Schleiser of how to >> participate in >> cm3/scripts/regression/README. Basically you need to checkout the >> scripts, install 5.4.0 manually once, and setup a cron job. >> >> We're mostly interested in the results of `tinderbox-build.sh >> cm3.build', >> which is the complete bootstrap and release build based on 5.4.0, >> as I think the lastok build need not run on all platforms. It's >> mainly >> there to detect incompatible changes. >> >> The release build includes the package and m3tests tests. >> >> If you want to participate, I'd suggest to setup everything and run >> it once without transferring your results, then enable the transfer >> in cm3.build: >> >> tinderbox_mailer() { >> true # needed if function is emtpy without this... >> # to report to the elego tinderbox host, check README and >> uncomment this: >> # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox >> /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" >> } >> >> That's all. Please let me know in advance if you setup the tests, >> >> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Mon Feb 18 05:26:17 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:26:17 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3. Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal. Compatibility with headers is problematic but very useful. This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language. It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > I'd rather not go this way and change the complete syntax and> convert to and fro between the two. If we really want to do that,> I'd rather have it as something like a compatible extension (as far> as possible).> > What about changing only the keywords from uppercase to lowercase> and using {} instead of BEGIN END? I'm not sure if that would> satisfy the C-adherents, and I'm also not sure if it would> introduce syntactic ambiguities, as {} are also used for sets.> I'd like to keep the changes to the syntactical structure minimal> (upper- and lowercase is only lexical matter after all). The abstract> syntax should be kept as it is.> > If something like this would be possible, I'd vote for supporting> both syntaxes in one compiler and turn on the C-style by a comment> or automatically by recognizing the first word of a module. I'd not> support mixing of styles within one module.> > Olaf> > PS: I'm not really suggesting we do this now, I just wanted to comment> on the possibility of doing something like this. Anyway it will> depend on somebody who provides appropriate patches and updates> the language specification etc.> > Quoting Mika Nystrom :> > > Well I used to be mostly a C programmer but I long since weaned> > myself off that syntax :)> >> > Your point of the post- and pre-increment might be a bit difficult> > for C programmers to stomach, but... well it is probably hard to> > tell what programmers will hate and what they will love.> >> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify> > the rules as needed? Would you like to be able to convert back and> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case> > all the keywords, convert the braces appropriately (a bit tricky> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most> > part)).> >> > Type "attributes"(is that the right word?) are also an area where> > Modula-3 is significantly different from the C family. In C, you> > write> >> > int *a, *b, c;> >> > we have> >> > REF INTEGER a, b;> > INTEGER c;> >> > And arrays?> >> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;> >> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];> >> > I prefer Algol syntax myself but I could definitely see that there> > might be people who would prefer a syntax mapped to C. One might> > be able to sneak Modula-3 into places where it wouldn't otherwise> > be used...> >> > Would it be possible to make "m3c" close enough in syntax that some> > simple C header files could be processed? Am I just being ridiculous> > now? A compiler that can process both C and Modula-3 in the same> > file?> >> > Python, by the way, provides some interesting hooks for C programs> > to interact with the Python garbage collector. Something similar> > could be done here. (But there is far less reason to write C code> > to plug into M3 than there is to write it to plug into Python.)> >> > Mika> >> >> > Darko writes:> >> If you like the idea, maybe you'd like join me in working out what> >> such a syntax would look like? Note that I want to keep the structure> >> the same, so no assignments in expressions, for example. Also, would C> >> programmers revolt at not having post and pre increment, also inside> >> expressions (as statements would be ok)? Requiring some sort of EVAL> >> statement? I guess the big question is whether removing these things> >> would make the whole idea unacceptable to the target audience. Does> >> the Algol syntax serve a purpose in making it clear that it isn't C?> >>> >>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:> >>> >>>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you> >>> can figure out how to turn Algol[Modula] back into C using <...>"...> >>>> >>> If you think it would help acceptance of Modula-3, I don't see why> >>> not?> >>>> >>> I copied the code exactly the way it came off the old half-inch> >>> tape from Berkeley.> >>>> >>> Darko writes:> >>>> I'm not sure what you're getting at or if I'm missing something> >>>> witty.> >>>> I've said the form of the keywords makes little or no difference in> >>>> my> >>>> opinion. In my mail you quote I say there should be a C like syntax> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a> >>>> matter of taste. I write in both all the time and it doesn't have any> >>>> impact on me, I go almost entirely by indentation, which I think is> >>>> very important. The indentation is pretty awful in code you posted> >>>> but> >>>> it could me my mailer.> >>>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:> >>> ...> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 18 05:41:29 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 20:41:29 -0800 Subject: [M3devel] code submission Message-ID: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> Hello everyone, I was looking at some code I've written and realized that I have a very small piece of tested code that may be of interest to other Modula-3 users. It's a generic "trie" that I coded a few years ago. Does anyone have an opinion on adding it to cm3? Where, if so? http://www.async.caltech.edu/~mika/trie/ It's useful for parsing; if you're parsing a language with longish keywords it is many times faster to use this structure and ARRAY OF CHAR than using the standard hash tables with TEXTs. (I developed it to parse an old "punch-card", i.e., 80-character fixed-width records, format for financial data.) Mika From wagner at elegosoft.com Mon Feb 18 08:32:39 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 08:32:39 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Message-ID: <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> Quoting Tony Hosking : > Solaris does not have %s for date -- we need an alternative for that > usage in tinderbox-build.sh. You mean as in date -u +'%Y-%m-%d-%H-%M-%S? It's used quite often: % grep -l date scripts/regression/*.sh scripts/regression/defs.sh scripts/regression/tinderbox-build.sh scripts/regression/tinderbox-status.sh scripts/regression/update_changelog.sh scripts/regression/update_m3tests.sh scripts/regression/update_pkg_status.sh scripts/regression/update_snapshot_status.sh Would it be possible, as a work-around, to install the GNU tools (date, sed, awk etc.)? I should have known something will fail on Solaris, because the standard command line utilities they ship are still bug-compatible to those from the 80s :-/ We've had lots of problems with them at one of our customers, too, and just installed openpkg as a stable environment. But I think GNU command line utilties should also be available as a Solaris package. If this is the only problem or if you cannot install an alternative environment, we'll have to do something about date. I'll make some tests later when I have access to a SPARC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 10:20:29 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 09:20:29 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Some corrections.. try to make braces work (with some alteration for C) >> for SETS Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "but" should say "punt" That is, this dialect of C that has some Modula-3 features, might have optional safety, or even garbage collection. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]Date: Mon, 18 Feb 2008 04:26:17 +0000 I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3.Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal.Compatibility with headers is problematic but very useful.This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language.It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > I'd rather not go this way and change the complete syntax and> convert to and fro between the two. If we really want to do that,> I'd rather have it as something like a compatible extension (as far> as possible).> > What about changing only the keywords from uppercase to lowercase> and using {} instead of BEGIN END? I'm not sure if that would> satisfy the C-adherents, and I'm also not sure if it would> introduce syntactic ambiguities, as {} are also used for sets.> I'd like to keep the changes to the syntactical structure minimal> (upper- and lowercase is only lexical matter after all). The abstract> syntax should be kept as it is.> > If something like this would be possible, I'd vote for supporting> both syntaxes in one compiler and turn on the C-style by a comment> or automatically by recognizing the first word of a module. I'd not> support mixing of styles within one module.> > Olaf> > PS: I'm not really suggesting we do this now, I just wanted to comment> on the possibility of doing something like this. Anyway it will> depend on somebody who provides appropriate patches and updates> the language specification etc.> > Quoting Mika Nystrom :> > > Well I used to be mostly a C programmer but I long since weaned> > myself off that syntax :)> >> > Your point of the post- and pre-increment might be a bit difficult> > for C programmers to stomach, but... well it is probably hard to> > tell what programmers will hate and what they will love.> >> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify> > the rules as needed? Would you like to be able to convert back and> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case> > all the keywords, convert the braces appropriately (a bit tricky> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most> > part)).> >> > Type "attributes"(is that the right word?) are also an area where> > Modula-3 is significantly different from the C family. In C, you> > write> >> > int *a, *b, c;> >> > we have> >> > REF INTEGER a, b;> > INTEGER c;> >> > And arrays?> >> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;> >> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];> >> > I prefer Algol syntax myself but I could definitely see that there> > might be people who would prefer a syntax mapped to C. One might> > be able to sneak Modula-3 into places where it wouldn't otherwise> > be used...> >> > Would it be possible to make "m3c" close enough in syntax that some> > simple C header files could be processed? Am I just being ridiculous> > now? A compiler that can process both C and Modula-3 in the same> > file?> >> > Python, by the way, provides some interesting hooks for C programs> > to interact with the Python garbage collector. Something similar> > could be done here. (But there is far less reason to write C code> > to plug into M3 than there is to write it to plug into Python.)> >> > Mika> >> >> > Darko writes:> >> If you like the idea, maybe you'd like join me in working out what> >> such a syntax would look like? Note that I want to keep the structure> >> the same, so no assignments in expressions, for example. Also, would C> >> programmers revolt at not having post and pre increment, also inside> >> expressions (as statements would be ok)? Requiring some sort of EVAL> >> statement? I guess the big question is whether removing these things> >> would make the whole idea unacceptable to the target audience. Does> >> the Algol syntax serve a purpose in making it clear that it isn't C?> >>> >>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:> >>> >>>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you> >>> can figure out how to turn Algol[Modula] back into C using <...>"...> >>>> >>> If you think it would help acceptance of Modula-3, I don't see why> >>> not?> >>>> >>> I copied the code exactly the way it came off the old half-inch> >>> tape from Berkeley.> >>>> >>> Darko writes:> >>>> I'm not sure what you're getting at or if I'm missing something> >>>> witty.> >>>> I've said the form of the keywords makes little or no difference in> >>>> my> >>>> opinion. In my mail you quote I say there should be a C like syntax> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a> >>>> matter of taste. I write in both all the time and it doesn't have any> >>>> impact on me, I go almost entirely by indentation, which I think is> >>>> very important. The indentation is pretty awful in code you posted> >>>> but> >>>> it could me my mailer.> >>>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:> >>> ...> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 18 11:34:34 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 11:34:34 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Message-ID: <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Quoting Tony Hosking : > Solaris does not have %s for date -- we need an alternative for that > usage in tinderbox-build.sh. You're probably talking about a different problem than I thought, at least % date -u +'%Y-%m-%d-%H-%M-%S' 2008-02-18-10-00-34 blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % type date date is hashed (/bin/date) blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % uname -a SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 seems to be working for me on Solaris. Ah, I've found it now: date +%s. Michael says it's not possible to do that with Sun's data. Openpkg for example comes with gdate, which understands the %s: % gdate "+%s" 1203329509 blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 % type gdate gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) gdate is part of the GNU coreutils. You can find it at http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml http://www.sunfreeware.com/programlistsparc10.html#coreutils Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Mon Feb 18 12:45:25 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Mon, 18 Feb 2008 12:45:25 +0100 Subject: [M3devel] List test Message-ID: <20080218124525.ego4vs4x4ok0gkko@mail.elegosoft.com> Please ignore. -- 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 hosking at cs.purdue.edu Mon Feb 18 14:39:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 08:39:23 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> Message-ID: No, I mean date '+%s', which just gives a raw time-stamp. date -u +'% Y-%m-%d-%H-%M-%S works just fine. I don't manage this machine so I'd like to avoid installing non- standard tools (if only so they don't get tangled up in the regression testing which should be done on a "vanilla" platform). On Feb 18, 2008, at 2:32 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Solaris does not have %s for date -- we need an alternative for that >> usage in tinderbox-build.sh. > > You mean as in date -u +'%Y-%m-%d-%H-%M-%S? > > It's used quite often: > % grep -l date scripts/regression/*.sh > scripts/regression/defs.sh > scripts/regression/tinderbox-build.sh > scripts/regression/tinderbox-status.sh > scripts/regression/update_changelog.sh > scripts/regression/update_m3tests.sh > scripts/regression/update_pkg_status.sh > scripts/regression/update_snapshot_status.sh > > Would it be possible, as a work-around, to install the GNU tools > (date, sed, awk etc.)? > > I should have known something will fail on Solaris, because the > standard command line utilities they ship are still bug-compatible > to those from the 80s :-/ We've had lots of problems with them > at one of our customers, too, and just installed openpkg as a stable > environment. But I think GNU command line utilties should also > be available as a Solaris package. > > If this is the only problem or if you cannot install an alternative > environment, we'll have to do something about date. I'll make some > tests later when I have access to a SPARC. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 14:41:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 08:41:49 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Message-ID: Yeah, perhaps I should install gdate. On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Solaris does not have %s for date -- we need an alternative for that >> usage in tinderbox-build.sh. > > You're probably talking about a different problem than I thought, > at least > > % date -u +'%Y-%m-%d-%H-%M-%S' > 2008-02-18-10-00-34 > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % type date > date is hashed (/bin/date) > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % uname -a > SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 > > seems to be working for me on Solaris. > > Ah, I've found it now: date +%s. > Michael says it's not possible to do that with Sun's data. > Openpkg for example comes with gdate, which understands the %s: > > % gdate "+%s" > 1203329509 > blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 > % type gdate > gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) > > gdate is part of the GNU coreutils. You can find it at > > http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml > > http://www.sunfreeware.com/programlistsparc10.html#coreutils > > Hope this helps, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 15:02:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 15:02:22 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> Message-ID: <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> Quoting Tony Hosking : > Yeah, perhaps I should install gdate. Is that acceptable then, or would you prefer that we write a small program (in C or M3) which only prints the seconds since the start of the epoch for the sake of tinderbox? Olaf > On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: > >> Quoting Tony Hosking : >> >>> Solaris does not have %s for date -- we need an alternative for that >>> usage in tinderbox-build.sh. >> >> You're probably talking about a different problem than I thought, >> at least >> >> % date -u +'%Y-%m-%d-%H-%M-%S' >> 2008-02-18-10-00-34 >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % type date >> date is hashed (/bin/date) >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % uname -a >> SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 >> >> seems to be working for me on Solaris. >> >> Ah, I've found it now: date +%s. >> Michael says it's not possible to do that with Sun's data. >> Openpkg for example comes with gdate, which understands the %s: >> >> % gdate "+%s" >> 1203329509 >> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >> % type gdate >> gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) >> >> gdate is part of the GNU coreutils. You can find it at >> >> http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml >> >> http://www.sunfreeware.com/programlistsparc10.html#coreutils >> >> Hope this helps, >> >> Olaf >> -- Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Feb 18 15:19:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 09:19:55 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> <20080218113434.4vntxn1m8s4wocss@mail.elegosoft.com> <20080218150222.7itl3x83cw00gwow@mail.elegosoft.com> Message-ID: <2BF46AA7-9BCA-4FFC-AE59-76707FFCC037@cs.purdue.edu> Yes, acceptable. I'll install gdate. On Feb 18, 2008, at 9:02 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Yeah, perhaps I should install gdate. > > Is that acceptable then, or would you prefer that we write a > small program (in C or M3) which only prints the seconds since the > start of the epoch for the sake of tinderbox? > > Olaf > >> On Feb 18, 2008, at 5:34 AM, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> Solaris does not have %s for date -- we need an alternative for >>>> that >>>> usage in tinderbox-build.sh. >>> >>> You're probably talking about a different problem than I thought, >>> at least >>> >>> % date -u +'%Y-%m-%d-%H-%M-%S' >>> 2008-02-18-10-00-34 >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % type date >>> date is hashed (/bin/date) >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % uname -a >>> SunOS blnsce005 5.9 Generic_118558-33 sun4u sparc SUNW,Sun-Fire-V490 >>> >>> seems to be working for me on Solaris. >>> >>> Ah, I've found it now: date +%s. >>> Michael says it's not possible to do that with Sun's data. >>> Openpkg for example comes with gdate, which understands the %s: >>> >>> % gdate "+%s" >>> 1203329509 >>> blnsce005 [/advantage/sm/yd/sdf/sm/impl] demx0x65 >>> % type gdate >>> gdate is hashed (/home/nightmar/openpkg-2.5/bin/gdate) >>> >>> gdate is part of the GNU coreutils. You can find it at >>> >>> http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml >>> >>> http://www.sunfreeware.com/programlistsparc10.html#coreutils >>> >>> Hope this helps, >>> >>> Olaf >>> -- Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >>> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 >>> 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Mon Feb 18 16:56:20 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 18 Feb 2008 10:56:20 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B60CE0.8050506@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> Message-ID: <47B9644F.1E75.00D7.1@scires.com> I use pickles extensively and they are used also by network objects. I've never used LAZYALIGN. My vote is that we don't break something (pickles/netobj) to add support for something that is rarely used. Regards, Randy >>> "Rodney M. Bates" 2/15/2008 5:06 PM >>> I'll put it in comments in the code. I am sure I can fix it to handle LAZYALIGN too, just not sure whether I can do it without requiring existing pickle files to be regenerated and/or existing code that reads/writes pickles to need recompilation. Anybody on this list who has code that might be affected if pickles or compiled code were invalidated by a change? I do propose we change the way of telling the compiler to do LAZYALIGN so that it is a property of a type and affects all variables of that type. Olaf Wagner wrote: > Perhaps we should check-in this description somewhere near the > actual code? Or is there enough documentation already? > > Olaf > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > Or at least put a big sticker on that it will break pickles. > > Quoting "Rodney M. Bates" : > >> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >> etc. only works for getting object layouts as on the machine executing >> the code, which is all that is needed when writing a pickle. >> >> When reading, Pickle code needs to know the layouts of a type both as >> it is on the reading machine and as it was on the machine that wrote >> the pickle. The type description that the compiler generates is >> excerpted and contains no field displacements, just lists of field >> types (which are either recursive type descriptions or builtin types). >> So it is independent of word sizes, etc. >> >> Pickles regenerates the displacements using the few target machine >> characteristics in a RTPacking.T It traverses a type description and >> simultaneously computes two sets of field displacements, both as they >> are on the reading machine and on the writing machine. For the latter, >> the value of RTPacking.T is (after a compact bit encoding) stored in the >> header of the pickle file. For the former, it's gotten by techniques >> like >> using BITSIZE. This is actually all done in RTTipe, part of m3core, and >> called by Pickle code. >> >> This is very fragile. RTTipe has to duplicate the compiler's layout >> behavior. There is no shared code. Making it common would involve >> quite a bit of rework, as the two use substantially different data >> structure and code organization. It will be obvious what kind of bit >> damage could occur if the two algorithms didn't agree. >> >> This is why I am obsessing over LAZYALIGN. I have been comparing the >> field displacement computations in RTTipe and in the compiler. The >> former is oblivious to LAZYALIGN. >> >> Note that all this is required even without any packing of small fields >> within words. E.G., a record with two INTEGER fields, pickled on a >> 32-bit machine and unpickled on a 64. >> >> Tony Hosking wrote: >> >>> Rodney, >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> would have thought all packing is done on word-sized units anyway. >>> Each side of the connection can check BITSIZE(LONGINT) to figure >>> out what to do presumably no differently from the way INTEGER is >>> communicated between 32-bit and 64-bit machines. Am I missing >>> something? >>> >>> -- Tony >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> (which can vary independently of the size of INTEGER). >>>>> 2) Variable length values of subrange bounds found in type >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> what the native word size can represent. >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>>> is not handled by Pickles. >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 >>> >>> >>> >>> >> >> -- >> ------------------------------------------------------------- >> 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 > > > > -- ------------------------------------------------------------- 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 Mon Feb 18 18:36:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 12:36:43 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B9644F.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> Message-ID: <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Can someone remind me again why we need LAZYALIGN? I concur with Randy that if it is rarely used and moreso breaks things I would argue to abandon it. On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add > support for something that is rarely used. > Regards, > Randy > > >>> "Rodney M. Bates" 2/15/2008 5:06 PM >>> > I'll put it in comments in the code. I am sure I can fix it to > handle LAZYALIGN too, just not sure whether I can do it without > requiring existing pickle files to be regenerated and/or existing > code that reads/writes pickles to need recompilation. > > Anybody on this list who has code that might be affected if pickles > or compiled code were invalidated by a change? > > I do propose we change the way of telling the compiler to do > LAZYALIGN so that it is a property of a type and affects all > variables of that type. > > Olaf Wagner wrote: > > Perhaps we should check-in this description somewhere near the > > actual code? Or is there enough documentation already? > > > > Olaf > > > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > > Or at least put a big sticker on that it will break pickles. > > > > Quoting "Rodney M. Bates" : > > > >> The word "Packing" in RTPacking is perhaps misleading. Using > BITSIZE, > >> etc. only works for getting object layouts as on the machine > executing > >> the code, which is all that is needed when writing a pickle. > >> > >> When reading, Pickle code needs to know the layouts of a type > both as > >> it is on the reading machine and as it was on the machine that > wrote > >> the pickle. The type description that the compiler generates is > >> excerpted and contains no field displacements, just lists of field > >> types (which are either recursive type descriptions or builtin > types). > >> So it is independent of word sizes, etc. > >> > >> Pickles regenerates the displacements using the few target machine > >> characteristics in a RTPacking.T It traverses a type > description and > >> simultaneously computes two sets of field displacements, both as > they > >> are on the reading machine and on the writing machine. For the > latter, > >> the value of RTPacking.T is (after a compact bit encoding) > stored in the > >> header of the pickle file. For the former, it's gotten by > techniques > >> like > >> using BITSIZE. This is actually all done in RTTipe, part of > m3core, and > >> called by Pickle code. > >> > >> This is very fragile. RTTipe has to duplicate the compiler's > layout > >> behavior. There is no shared code. Making it common would involve > >> quite a bit of rework, as the two use substantially different data > >> structure and code organization. It will be obvious what kind > of bit > >> damage could occur if the two algorithms didn't agree. > >> > >> This is why I am obsessing over LAZYALIGN. I have been > comparing the > >> field displacement computations in RTTipe and in the compiler. The > >> former is oblivious to LAZYALIGN. > >> > >> Note that all this is required even without any packing of small > fields > >> within words. E.G., a record with two INTEGER fields, pickled on a > >> 32-bit machine and unpickled on a 64. > >> > >> Tony Hosking wrote: > >> > >>> Rodney, > >>> > >>> Why does there need to be an entry for LONGINT in RTPacking? I > >>> would have thought all packing is done on word-sized units > anyway. > >>> Each side of the connection can check BITSIZE(LONGINT) to figure > >>> out what to do presumably no differently from the way INTEGER is > >>> communicated between 32-bit and 64-bit machines. Am I missing > >>> something? > >>> > >>> -- Tony > >>> > >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >>> > >>>> Ah, OK. I don't much delve in pickle-land. Anything I can > help with? > >>>> > >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >>>> > >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, > >>>>> (which can vary independently of the size of INTEGER). > >>>>> 2) Variable length values of subrange bounds found in type > >>>>> descriptions (in TipeDesc.i3) can now have values beyond > >>>>> what the native word size can represent. > >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added > recently) > >>>>> is not handled by Pickles. > >>>>> > >>>>> I have done some coding on this, but have been interrupted. > >>>>> > >>>>> Tony Hosking wrote: > >>>>> > >>>>>> Why is LONGINT for pickles not yet supported? > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> ------------------------------------------------------------- > >>>>> 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 > >>> > >>> > >>> > >>> > >> > >> -- > >> ------------------------------------------------------------- > >> 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 > > > > > > > > > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Mon Feb 18 19:55:53 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 10:55:53 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 18 Feb 2008 16:16:44." <20080218151644.E5E4410D4331@birch.elegosoft.com> Message-ID: <200802181855.m1IItr0w032707@camembert.async.caltech.edu> Jay Krell writes: >CVSROOT: /usr/cvs >Changes by: jkrell at birch. 08/02/18 16:16:44 > >Modified files: > cm3/m3-sys/m3quake/src/: QMachine.i3 QMachine.m3 > cm3/m3-sys/cm3/src/: M3Path.m3 > >Log message: > At least for purposes of determining if Join(a,b) is b or a + slash + b, > treat any path that starts with a forward or backward slash, or > contains a colon as the second character, as absolute, on all platforms. > It is ASSUMED that backslashes and colons are never used in paths > on non-Windows systems, or at least that this interpretation is ok. I think people are careful not to use backslashes on Unix because it does weird things in the shell, so "it's not surprising" if things go bad if you use backslashes in your filenames. I know I never have, on purpose. But colons? Colons are not special in any way, shape, or form, on Unix... I think "it is extremely surprising" to a Unix user if a path with a colon in it breaks something. Mika From wagner at elegosoft.com Mon Feb 18 20:35:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 20:35:36 +0100 Subject: [M3devel] code submission In-Reply-To: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> References: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> Message-ID: <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> Quoting Mika Nystrom : > Hello everyone, > > I was looking at some code I've written and realized that I have a > very small piece of tested code that may be of interest to other > Modula-3 users. It's a generic "trie" that I coded a few years > ago. Does anyone have an opinion on adding it to cm3? Where, if so? > > http://www.async.caltech.edu/~mika/trie/ > > It's useful for parsing; if you're parsing a language with longish > keywords it is many times faster to use this structure and ARRAY > OF CHAR than using the standard hash tables with TEXTs. (I developed > it to parse an old "punch-card", i.e., 80-character fixed-width > records, format for financial data.) Of course we could add this as a small package to m3-libs, or even to libm3 (it looks rather small). I hate to sound so uneducated, but what exactly does `trie' stand for? It's not contained in my favourite online dictionary either. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 18 20:37:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 19:37:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802181855.m1IItr0w032707@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 16:16:44." <20080218151644.E5E4410D4331@birch.elegosoft.com> <200802181855.m1IItr0w032707@camembert.async.caltech.edu> Message-ID: > But colons? Colons are not special in any way, shape, or form, on> Unix... I think "it is extremely surprising" to a Unix user if a path Ever try putting a path with a colon into $PATH? Does it work? Or copying a file with a colon in its name to a Windows system? Does it work? This part could be limited to systems that have $OS == Windows_NT I guess. As a user switching between multiple systems, this area is quite frustrating...I guess no matter what. Sometimes one form works, sometimes another, sometimes either, often with identical meaning, but not always. These changes, and about one more, should make building NT386GNU a fair amount easier.. Currently it is any path with a colon in the second character. How about if that is further restricted to having a-z in the first character and/or more importantly a slash in the third character? - Jay > To: jkrell at elego.de> Date: Mon, 18 Feb 2008 10:55:53 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay Krell writes:> >CVSROOT: /usr/cvs> >Changes by: jkrell at birch. 08/02/18 16:16:44> >> >Modified files:> > cm3/m3-sys/m3quake/src/: QMachine.i3 QMachine.m3 > > cm3/m3-sys/cm3/src/: M3Path.m3 > >> >Log message:> > At least for purposes of determining if Join(a,b) is b or a + slash + b,> > treat any path that starts with a forward or backward slash, or> > contains a colon as the second character, as absolute, on all platforms.> > It is ASSUMED that backslashes and colons are never used in paths> > on non-Windows systems, or at least that this interpretation is ok.> > I think people are careful not to use backslashes on Unix because> it does weird things in the shell, so "it's not surprising" if> things go bad if you use backslashes in your filenames. I know I> never have, on purpose.> > But colons? Colons are not special in any way, shape, or form, on> Unix... I think "it is extremely surprising" to a Unix user if a path> with a colon in it breaks something. > > Mika _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 18 20:50:20 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 19:50:20 +0000 Subject: [M3devel] code submission In-Reply-To: <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> References: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> <20080218203536.kt9fcfycoo8wko04@mail.elegosoft.com> Message-ID: aka "prefix tree" if I want to recognize the strings, foo, food, fudge, and bar look at the first character if it is 'b', go ahead and compare to bar (or the tail to "ar") if it is 'f' look at the second character if it is 'u', go ahead and compare to "fudge" (or the tail to "dge") if it 'o' compare the third character and so on Whether or not the data "stops" at unique prefixes is an implementation detail. If it does, the leaves can contain the entire string or just the tail. I've fiddled with generating large nested switch statements from a list of strings. I noticed there are many optimizations you can make. Of course, first you check the length. Then, really, instead of progressing from left to right, you can pick out characters with a higher switching factor. For example if I have the strings foof and food, just look at the last character. As well a hash based algorithm is probably best. Precompute the hashes of all the strings. Sor them. Hash your input string. Binary search for the hash. And the compare for an exact match. If you are going to do the final compare anyway, then you are going to touch the whole string anyway, you might as well hash it and do a binary search I think. Make sure the hash function is fast of course, and not "perfect". - Jay > Date: Mon, 18 Feb 2008 20:35:36 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] code submission> > Quoting Mika Nystrom :> > > Hello everyone,> >> > I was looking at some code I've written and realized that I have a> > very small piece of tested code that may be of interest to other> > Modula-3 users. It's a generic "trie" that I coded a few years> > ago. Does anyone have an opinion on adding it to cm3? Where, if so?> >> > http://www.async.caltech.edu/~mika/trie/> >> > It's useful for parsing; if you're parsing a language with longish> > keywords it is many times faster to use this structure and ARRAY> > OF CHAR than using the standard hash tables with TEXTs. (I developed> > it to parse an old "punch-card", i.e., 80-character fixed-width> > records, format for financial data.)> > Of course we could add this as a small package to m3-libs, or> even to libm3 (it looks rather small).> > I hate to sound so uneducated, but what exactly does `trie' stand for?> It's not contained in my favourite online dictionary either.> > Olaf> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Feb 18 21:01:39 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 07:01:39 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: The alignment behaviour is absolutely crucial to programming natively in Mac OS X and should be kept. I have a great need for it. The PRGAMA is of no use and can be removed. Does anyone have any objections to making this alignment behaviour standard? On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > Can someone remind me again why we need LAZYALIGN? I concur with > Randy that if it is rarely used and moreso breaks things I would > argue to abandon it. > > On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > >> I use pickles extensively and they are used also by network objects. >> I've never used LAZYALIGN. >> My vote is that we don't break something (pickles/netobj) to add >> support for something that is rarely used. >> Regards, >> Randy >> >> >>> "Rodney M. Bates" 2/15/2008 5:06 PM >> >>> >> I'll put it in comments in the code. I am sure I can fix it to >> handle LAZYALIGN too, just not sure whether I can do it without >> requiring existing pickle files to be regenerated and/or existing >> code that reads/writes pickles to need recompilation. >> >> Anybody on this list who has code that might be affected if pickles >> or compiled code were invalidated by a change? >> >> I do propose we change the way of telling the compiler to do >> LAZYALIGN so that it is a property of a type and affects all >> variables of that type. >> >> Olaf Wagner wrote: >> > Perhaps we should check-in this description somewhere near the >> > actual code? Or is there enough documentation already? >> > >> > Olaf >> > >> > PS: Based on your description, I'd say we should abandon LAZYALIGN. >> > Or at least put a big sticker on that it will break pickles. >> > >> > Quoting "Rodney M. Bates" : >> > >> >> The word "Packing" in RTPacking is perhaps misleading. Using >> BITSIZE, >> >> etc. only works for getting object layouts as on the machine >> executing >> >> the code, which is all that is needed when writing a pickle. >> >> >> >> When reading, Pickle code needs to know the layouts of a type >> both as >> >> it is on the reading machine and as it was on the machine that >> wrote >> >> the pickle. The type description that the compiler generates is >> >> excerpted and contains no field displacements, just lists of field >> >> types (which are either recursive type descriptions or builtin >> types). >> >> So it is independent of word sizes, etc. >> >> >> >> Pickles regenerates the displacements using the few target machine >> >> characteristics in a RTPacking.T It traverses a type >> description and >> >> simultaneously computes two sets of field displacements, both as >> they >> >> are on the reading machine and on the writing machine. For the >> latter, >> >> the value of RTPacking.T is (after a compact bit encoding) >> stored in the >> >> header of the pickle file. For the former, it's gotten by >> techniques >> >> like >> >> using BITSIZE. This is actually all done in RTTipe, part of >> m3core, and >> >> called by Pickle code. >> >> >> >> This is very fragile. RTTipe has to duplicate the compiler's >> layout >> >> behavior. There is no shared code. Making it common would >> involve >> >> quite a bit of rework, as the two use substantially different data >> >> structure and code organization. It will be obvious what kind >> of bit >> >> damage could occur if the two algorithms didn't agree. >> >> >> >> This is why I am obsessing over LAZYALIGN. I have been >> comparing the >> >> field displacement computations in RTTipe and in the compiler. >> The >> >> former is oblivious to LAZYALIGN. >> >> >> >> Note that all this is required even without any packing of small >> fields >> >> within words. E.G., a record with two INTEGER fields, pickled >> on a >> >> 32-bit machine and unpickled on a 64. >> >> >> >> Tony Hosking wrote: >> >> >> >>> Rodney, >> >>> >> >>> Why does there need to be an entry for LONGINT in RTPacking? I >> >>> would have thought all packing is done on word-sized units >> anyway. >> >>> Each side of the connection can check BITSIZE(LONGINT) to >> figure >> >>> out what to do presumably no differently from the way INTEGER is >> >>> communicated between 32-bit and 64-bit machines. Am I missing >> >>> something? >> >>> >> >>> -- Tony >> >>> >> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> >> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >> help with? >> >>>> >> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >> >>>> >> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >> >>>>> (which can vary independently of the size of INTEGER). >> >>>>> 2) Variable length values of subrange bounds found in type >> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >> >>>>> what the native word size can represent. >> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >> recently) >> >>>>> is not handled by Pickles. >> >>>>> >> >>>>> I have done some coding on this, but have been interrupted. >> >>>>> >> >>>>> Tony Hosking wrote: >> >>>>> >> >>>>>> Why is LONGINT for pickles not yet supported? >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> ------------------------------------------------------------- >> >>>>> 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 >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> ------------------------------------------------------------- >> >> 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 >> > >> > >> > >> > >> >> -- >> ------------------------------------------------------------- >> 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 hosking at cs.purdue.edu Mon Feb 18 22:32:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 16:32:46 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: On Feb 18, 2008, at 3:01 PM, Darko wrote: > The alignment behaviour is absolutely crucial to programming > natively in Mac OS X and should be kept. I have a great need for it. > > The PRGAMA is of no use and can be removed. > > Does anyone have any objections to making this alignment behaviour > standard? What do you mean make LAZYALIGN standard? Why wouldn't we go with the standard gcc-backend alignment? Perhaps I don't understand what it is you are doing or trying to do. Again, please remind me what it is that LAZYALIGN does and why it is needed. > On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > >> Can someone remind me again why we need LAZYALIGN? I concur with >> Randy that if it is rarely used and moreso breaks things I would >> argue to abandon it. >> >> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >> >>> I use pickles extensively and they are used also by network objects. >>> I've never used LAZYALIGN. >>> My vote is that we don't break something (pickles/netobj) to add >>> support for something that is rarely used. >>> Regards, >>> Randy >>> >>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>> PM >>> >>> I'll put it in comments in the code. I am sure I can fix it to >>> handle LAZYALIGN too, just not sure whether I can do it without >>> requiring existing pickle files to be regenerated and/or existing >>> code that reads/writes pickles to need recompilation. >>> >>> Anybody on this list who has code that might be affected if pickles >>> or compiled code were invalidated by a change? >>> >>> I do propose we change the way of telling the compiler to do >>> LAZYALIGN so that it is a property of a type and affects all >>> variables of that type. >>> >>> Olaf Wagner wrote: >>> > Perhaps we should check-in this description somewhere near the >>> > actual code? Or is there enough documentation already? >>> > >>> > Olaf >>> > >>> > PS: Based on your description, I'd say we should abandon >>> LAZYALIGN. >>> > Or at least put a big sticker on that it will break pickles. >>> > >>> > Quoting "Rodney M. Bates" : >>> > >>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>> BITSIZE, >>> >> etc. only works for getting object layouts as on the machine >>> executing >>> >> the code, which is all that is needed when writing a pickle. >>> >> >>> >> When reading, Pickle code needs to know the layouts of a type >>> both as >>> >> it is on the reading machine and as it was on the machine that >>> wrote >>> >> the pickle. The type description that the compiler generates is >>> >> excerpted and contains no field displacements, just lists of >>> field >>> >> types (which are either recursive type descriptions or builtin >>> types). >>> >> So it is independent of word sizes, etc. >>> >> >>> >> Pickles regenerates the displacements using the few target >>> machine >>> >> characteristics in a RTPacking.T It traverses a type >>> description and >>> >> simultaneously computes two sets of field displacements, both >>> as they >>> >> are on the reading machine and on the writing machine. For >>> the latter, >>> >> the value of RTPacking.T is (after a compact bit encoding) >>> stored in the >>> >> header of the pickle file. For the former, it's gotten by >>> techniques >>> >> like >>> >> using BITSIZE. This is actually all done in RTTipe, part of >>> m3core, and >>> >> called by Pickle code. >>> >> >>> >> This is very fragile. RTTipe has to duplicate the compiler's >>> layout >>> >> behavior. There is no shared code. Making it common would >>> involve >>> >> quite a bit of rework, as the two use substantially different >>> data >>> >> structure and code organization. It will be obvious what kind >>> of bit >>> >> damage could occur if the two algorithms didn't agree. >>> >> >>> >> This is why I am obsessing over LAZYALIGN. I have been >>> comparing the >>> >> field displacement computations in RTTipe and in the >>> compiler. The >>> >> former is oblivious to LAZYALIGN. >>> >> >>> >> Note that all this is required even without any packing of >>> small fields >>> >> within words. E.G., a record with two INTEGER fields, pickled >>> on a >>> >> 32-bit machine and unpickled on a 64. >>> >> >>> >> Tony Hosking wrote: >>> >> >>> >>> Rodney, >>> >>> >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> >>> would have thought all packing is done on word-sized units >>> anyway. >>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>> figure >>> >>> out what to do presumably no differently from the way >>> INTEGER is >>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>> >>> something? >>> >>> >>> >>> -- Tony >>> >>> >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>> >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>> help with? >>> >>>> >>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> >>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>> >>>>> (which can vary independently of the size of INTEGER). >>> >>>>> 2) Variable length values of subrange bounds found in type >>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>> >>>>> what the native word size can represent. >>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>> recently) >>> >>>>> is not handled by Pickles. >>> >>>>> >>> >>>>> I have done some coding on this, but have been interrupted. >>> >>>>> >>> >>>>> Tony Hosking wrote: >>> >>>>> >>> >>>>>> Why is LONGINT for pickles not yet supported? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> ------------------------------------------------------------- >>> >>>>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >> -- >>> >> ------------------------------------------------------------- >>> >> 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 >>> > >>> > >>> > >>> > >>> >>> -- >>> ------------------------------------------------------------- >>> 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 mika at async.caltech.edu Mon Feb 18 23:04:06 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 14:04:06 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." Message-ID: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> I never tried putting it in my PATH, no... You are right, colons are *slightly* special. I am not in the habit of copying files to Windows. I only copy files between Unix and Windows to save them from Windows. That being said, I am pretty sure I use colons more in filenames than I use the letter "q". Could you ban the letter "q" instead? :) If you've gotta do it, then do it. It's just ... weird. I personally will probably never run into the issue. I use colons in filenames a lot, but as a separator for various types of data files. :. Is your code able to import (or duplicate...) Pathname? I would have thought that that interface has all the necessary bits to make paths portable... MIka Jay writes: >--_dfd4e29a-b904-43be-8435-4824d419d270_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> But colons? Colons are not special in any way, shape, or form, on> Unix..= >. I think "it is extremely surprising" to a Unix user if a path >Ever try putting a path with a colon into $PATH? Does it work? >Or copying a file with a colon in its name to a Windows system? Does it wor= >k? >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue= >ss. >=20 >As a user switching between multiple systems, this area is quite frustratin= >g...I guess no matter what. >Sometimes one form works, sometimes another, sometimes either, often with i= >dentical meaning, but not always. >These changes, and about one more, should make building NT386GNU a fair amo= >unt easier.. >=20 >Currently it is any path with a colon in the second character. >How about if that is further restricted to having a-z in the first characte= >r and/or more importantly a slash in the third character? >=20 > - Jay > > > From jayk123 at hotmail.com Mon Feb 18 23:27:56 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 22:27:56 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: I'm going to work on this more but not today. I will at least restrict it to check that the next character is a slash. I'm not sure that will satisfy folks. The Pathname module is/was being used but is a little unsatisfactory. > I use colons in filenames a lot Do you use it in source files? For "root" directories, like where your cm3 install/source is? I'm trying to think/wiggle through what might be an acceptable escape. Something like -- where files in general are vs. where "programmer" files are. Putting a colon in a filename really is quite non-portable. And that may or may not matter. The existing Modula-3 code was fairly strict and I very unsure it was right. I had a question drafted to m3devel that I ended up not sending. It went roughly like: " Has anyone done a cross build where host and target vary in naming conventions? I am skeptical that this works, and am strongly considering /slightly/ depending on that or making it "worse". In particular, there is provision in the code for "converting" between host and target paths, but all it does is translate slashes. It doesn't translate libfoo.a to foo.lib for example. " Upon further digging though, I decide that my more immediate severe problem could be dealt with not by making things worse but by making them better. This is the change around checking NAMING_CONVENTIONS earlier. While my analysis was not 100% thorough, it is my very strong suspicion that the NAMING_CONVENTION and undocumented TARGET_NAMING configuration variables never really worked. Sure, they affected the name of the .m3x file. But that is about it. I didn't check .exes, but probably didn't work, and what I was seeing was they didn't work for libraries. M3Path.m3 sets up one set of path data in three ways. variable initialization (VAR foo := 123) module initialization (BEGIN foo := 456 END Module.) and explicit calls after reading the config file The problem was that the explicit calls were very late, so the module initialization is what held. If Join(a,b) == a/b, then you'd get Unix naming conventions. /Arguably/ this is exactly correct. But I would like the slash and the "naming" to be separate, at least for now. That is, NT386GNU uses forward slashes but foo.lib instead of libfoo.a. I should try to change that actually. I had trouble changing it for this reason since I was cross building from NT386. The NT386 HOST wants to use Win32 naming conventions, "\" and foo.lib, even if the config file asks for Unix naming.. Anyway, this is all somewhat of a tangent, one in which I'm more confident of where to go and that what I changed is ok. (It might become irrelevant.) The other issues are around "difficulty" setting paths. I had CM3_ROOT=c:\dev2\cm3.2. That wouldn't necessarily work with NT386GNU. It seems darn near possible to have one path syntax and one set of code for dealing with it. But maybe not. Even semicolon vs. colon seems doable. Specifically, if an element of $PATH appears to be just a single character, that colon is not a $PATH divider. Perhaps I just need to have two sets of CM3_ROOT / CM3_INSTALL and perhaps M3CONFIG variables. I was kind of hoping not. It's worse than that really, since the two hosts can target the two targets, so host and target paths needs to be better distinguished than I believe the are now. I was saying there is code to change the slashes, but there isn't code to deal with a leading drive letter. What I have been particularly avoiding is calls out to cygwin_convert_path or such, but maybe that's what I need to do. Get ROOT / CM3_INSTALL etc. from the command line and environment, convert as appropriate, and move on. ROOT in particular is set by Python. Usually for me that is Win32 Python, but Cygwin Python is an option. So then Python has to know what cm3 it is running? I considered probing it with findstr /i /m cm3.exe cygwin1.dll. I considered something like cm3 -report_something_or_other, kind of like gcc has -print-gcc-lib-name or whatnot. These might still be viable ideas. Historically cross environments don't allow multiple "targets" / "platforms" / "configurations" / "whatever" to run on the same OS. But there is some of an opposite trend. Like how NT386 and NT386GNU run on the same OS. Like SOLsun, SOLgnu. Like x86 on AMD64 operating systems. So maybe a little bit of support is good there, the cm3 -print-slash or cm3 -print-host or something. Also I forgot to point out that Win32 is often find with forward slashes, but notable file.open dialogs are not. I very frequently copy compiler output to file.open dialogs so in some places backward slashes are preferred. A possible strategy is to sniff what the user is using -- such as in any of those environment variables -- and favor it. Or for each Join operating harvest a path separater from the parameters and default if there is none there. I have some code working like that last option right now but it's not quite working and has to wait. It is very reasonable to have Win32 treat forward and backward slashes as the same, in particular. It is fairly reasonable imho for Posix code to also treat them the same but "fixup" backward to forward. As well, on Windows, if you mostly limit yourself to one drive letter, then /foo/bar is a pretty acceptable form.. Anyway...lots of facts, some easy conclusions, some unclear conclusions. I'll fiddle around with it more later. Ideally switching between NT386 and NT386GNU is fairly easy.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 18 Feb 2008 14:04:06 -0800> From: mika at async.caltech.edu> > > I never tried putting it in my PATH, no... You are right, colons> are *slightly* special. I am not in the habit of copying files to> Windows. I only copy files between Unix and Windows to save them> from Windows.> > That being said, I am pretty sure I use colons more in filenames> than I use the letter "q". Could you ban the letter "q" instead? :)> > If you've gotta do it, then do it. It's just ... weird.> > I personally will probably never run into the issue. I use colons> in filenames a lot, but as a separator for various types of data> files. :.> > Is your code able to import (or duplicate...) Pathname? I would> have thought that that interface has all the necessary bits to make> paths portable...> > MIka> > Jay writes:> >--_dfd4e29a-b904-43be-8435-4824d419d270_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> But colons? Colons are not special in any way, shape, or form, on> Unix..=> >. I think "it is extremely surprising" to a Unix user if a path> >Ever try putting a path with a colon into $PATH? Does it work?> >Or copying a file with a colon in its name to a Windows system? Does it wor=> >k?> >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue=> >ss.> >=20> >As a user switching between multiple systems, this area is quite frustratin=> >g...I guess no matter what.> >Sometimes one form works, sometimes another, sometimes either, often with i=> >dentical meaning, but not always.> >These changes, and about one more, should make building NT386GNU a fair amo=> >unt easier..> >=20> >Currently it is any path with a colon in the second character.> >How about if that is further restricted to having a-z in the first characte=> >r and/or more importantly a slash in the third character?> >=20> > - Jay> >> >> > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Feb 19 02:44:02 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 02:44:02 +0100 (CET) Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> Message-ID: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Actually rather than compilain rather grumpily, maybe I can just make the changes required to RTTipe and do the work to reomve the pragma. I can work with Randy to ensure it doesn't break pickles, there is no reason why it should. On tha subject Randy, I assume pickles encode the number of BITS FOR for a field? If not it should. > We seem to be going through these same point several times. I'm not sure > what the difficulty is, I'm just repeating myself. > > Keep in mind this applies *only* to packed structures, ie BIT FOR or bit > fields. > > The change I put in libralised the *M3* alignment rules so that BITS FOR > fields in structures would align on byte boundries if possible instead of > restricting them to word alignment generally. GCC happily generates code > for this. There may be restrictions in GCC's C as to how you can arrange > bit fields but I don't see what they have to do with M3. > > This is absolutely essentail for using the native APIs on Mac OS X and its > removal would make M3 pointless for use on the Mac, at least more me. > > This should be the default behviour. If you are using BITS FOR it's > becuase you want to arrange the fields in a record in particular way. Why > then arbitrarliy pad out the fields? If performance is an issue, the user > should be using appropriate field bit sizes. The implementation rule for > BITS FOR in M3 is implementation dependent, there are no language issues. > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > created and had nothing to do with me. I diagreed with it and never used > it in the version of the compiler I ran. I support its removal. > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: >> >>> The alignment behaviour is absolutely crucial to programming >>> natively in Mac OS X and should be kept. I have a great need for it. >>> >>> The PRGAMA is of no use and can be removed. >>> >>> Does anyone have any objections to making this alignment behaviour >>> standard? >> >> What do you mean make LAZYALIGN standard? Why wouldn't we go with >> the standard gcc-backend alignment? Perhaps I don't understand what >> it is you are doing or trying to do. Again, please remind me what it >> is that LAZYALIGN does and why it is needed. >> >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>> >>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>> Randy that if it is rarely used and moreso breaks things I would >>>> argue to abandon it. >>>> >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>> >>>>> I use pickles extensively and they are used also by network objects. >>>>> I've never used LAZYALIGN. >>>>> My vote is that we don't break something (pickles/netobj) to add >>>>> support for something that is rarely used. >>>>> Regards, >>>>> Randy >>>>> >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>>> PM >>> >>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>> requiring existing pickle files to be regenerated and/or existing >>>>> code that reads/writes pickles to need recompilation. >>>>> >>>>> Anybody on this list who has code that might be affected if pickles >>>>> or compiled code were invalidated by a change? >>>>> >>>>> I do propose we change the way of telling the compiler to do >>>>> LAZYALIGN so that it is a property of a type and affects all >>>>> variables of that type. >>>>> >>>>> Olaf Wagner wrote: >>>>> > Perhaps we should check-in this description somewhere near the >>>>> > actual code? Or is there enough documentation already? >>>>> > >>>>> > Olaf >>>>> > >>>>> > PS: Based on your description, I'd say we should abandon >>>>> LAZYALIGN. >>>>> > Or at least put a big sticker on that it will break pickles. >>>>> > >>>>> > Quoting "Rodney M. Bates" : >>>>> > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>>> BITSIZE, >>>>> >> etc. only works for getting object layouts as on the machine >>>>> executing >>>>> >> the code, which is all that is needed when writing a pickle. >>>>> >> >>>>> >> When reading, Pickle code needs to know the layouts of a type >>>>> both as >>>>> >> it is on the reading machine and as it was on the machine that >>>>> wrote >>>>> >> the pickle. The type description that the compiler generates is >>>>> >> excerpted and contains no field displacements, just lists of >>>>> field >>>>> >> types (which are either recursive type descriptions or builtin >>>>> types). >>>>> >> So it is independent of word sizes, etc. >>>>> >> >>>>> >> Pickles regenerates the displacements using the few target >>>>> machine >>>>> >> characteristics in a RTPacking.T It traverses a type >>>>> description and >>>>> >> simultaneously computes two sets of field displacements, both >>>>> as they >>>>> >> are on the reading machine and on the writing machine. For >>>>> the latter, >>>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>>> stored in the >>>>> >> header of the pickle file. For the former, it's gotten by >>>>> techniques >>>>> >> like >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>>> m3core, and >>>>> >> called by Pickle code. >>>>> >> >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>>> layout >>>>> >> behavior. There is no shared code. Making it common would >>>>> involve >>>>> >> quite a bit of rework, as the two use substantially different >>>>> data >>>>> >> structure and code organization. It will be obvious what kind >>>>> of bit >>>>> >> damage could occur if the two algorithms didn't agree. >>>>> >> >>>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>>> comparing the >>>>> >> field displacement computations in RTTipe and in the >>>>> compiler. The >>>>> >> former is oblivious to LAZYALIGN. >>>>> >> >>>>> >> Note that all this is required even without any packing of >>>>> small fields >>>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>>> on a >>>>> >> 32-bit machine and unpickled on a 64. >>>>> >> >>>>> >> Tony Hosking wrote: >>>>> >> >>>>> >>> Rodney, >>>>> >>> >>>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>> >>> would have thought all packing is done on word-sized units >>>>> anyway. >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>>> figure >>>>> >>> out what to do presumably no differently from the way >>>>> INTEGER is >>>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>>> >>> something? >>>>> >>> >>>>> >>> -- Tony >>>>> >>> >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>> >>> >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>> help with? >>>>> >>>> >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>> >>>> >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> >>>>> (which can vary independently of the size of INTEGER). >>>>> >>>>> 2) Variable length values of subrange bounds found in type >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> >>>>> what the native word size can represent. >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>> recently) >>>>> >>>>> is not handled by Pickles. >>>>> >>>>> >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>> >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------------------------------------------------------------- >>>>> >>>>> 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 >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> -- >>>>> >> ------------------------------------------------------------- >>>>> >> 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 >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 hosking at cs.purdue.edu Tue Feb 19 05:40:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2008 23:40:47 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Message-ID: <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> Thanks for the explanation! How does one express the alignment you support? It does sound like <*LAZYALIGN*> can go away. On Feb 18, 2008, at 8:44 PM, Darko wrote: > Actually rather than compilain rather grumpily, maybe I can just > make the > changes required to RTTipe and do the work to reomve the pragma. I can > work with Randy to ensure it doesn't break pickles, there is no > reason why > it should. > > On tha subject Randy, I assume pickles encode the number of BITS FOR > for a field? If not it should. > > >> We seem to be going through these same point several times. I'm >> not sure >> what the difficulty is, I'm just repeating myself. >> >> Keep in mind this applies *only* to packed structures, ie BIT FOR >> or bit >> fields. >> >> The change I put in libralised the *M3* alignment rules so that >> BITS FOR >> fields in structures would align on byte boundries if possible >> instead of >> restricting them to word alignment generally. GCC happily >> generates code >> for this. There may be restrictions in GCC's C as to how you can >> arrange >> bit fields but I don't see what they have to do with M3. >> >> This is absolutely essentail for using the native APIs on Mac OS X >> and its >> removal would make M3 pointless for use on the Mac, at least more me. >> >> This should be the default behviour. If you are using BITS FOR it's >> becuase you want to arrange the fields in a record in particular >> way. Why >> then arbitrarliy pad out the fields? If performance is an issue, >> the user >> should be using appropriate field bit sizes. The implementation >> rule for >> BITS FOR in M3 is implementation dependent, there are no language >> issues. >> >> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >> created and had nothing to do with me. I diagreed with it and >> never used >> it in the version of the compiler I ran. I support its removal. >> >> >> >>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>> >>>> The alignment behaviour is absolutely crucial to programming >>>> natively in Mac OS X and should be kept. I have a great need for >>>> it. >>>> >>>> The PRGAMA is of no use and can be removed. >>>> >>>> Does anyone have any objections to making this alignment behaviour >>>> standard? >>> >>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>> the standard gcc-backend alignment? Perhaps I don't understand what >>> it is you are doing or trying to do. Again, please remind me >>> what it >>> is that LAZYALIGN does and why it is needed. >>> >>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>> >>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>> Randy that if it is rarely used and moreso breaks things I would >>>>> argue to abandon it. >>>>> >>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>> >>>>>> I use pickles extensively and they are used also by network >>>>>> objects. >>>>>> I've never used LAZYALIGN. >>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>> support for something that is rarely used. >>>>>> Regards, >>>>>> Randy >>>>>> >>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>> PM >>> >>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>> requiring existing pickle files to be regenerated and/or existing >>>>>> code that reads/writes pickles to need recompilation. >>>>>> >>>>>> Anybody on this list who has code that might be affected if >>>>>> pickles >>>>>> or compiled code were invalidated by a change? >>>>>> >>>>>> I do propose we change the way of telling the compiler to do >>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>> variables of that type. >>>>>> >>>>>> Olaf Wagner wrote: >>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>> actual code? Or is there enough documentation already? >>>>>>> >>>>>>> Olaf >>>>>>> >>>>>>> PS: Based on your description, I'd say we should abandon >>>>>> LAZYALIGN. >>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>> >>>>>>> Quoting "Rodney M. Bates" : >>>>>>> >>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>> BITSIZE, >>>>>>>> etc. only works for getting object layouts as on the machine >>>>>> executing >>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>> >>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>> both as >>>>>>>> it is on the reading machine and as it was on the machine that >>>>>> wrote >>>>>>>> the pickle. The type description that the compiler >>>>>>>> generates is >>>>>>>> excerpted and contains no field displacements, just lists of >>>>>> field >>>>>>>> types (which are either recursive type descriptions or builtin >>>>>> types). >>>>>>>> So it is independent of word sizes, etc. >>>>>>>> >>>>>>>> Pickles regenerates the displacements using the few target >>>>>> machine >>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>> description and >>>>>>>> simultaneously computes two sets of field displacements, both >>>>>> as they >>>>>>>> are on the reading machine and on the writing machine. For >>>>>> the latter, >>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>> stored in the >>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>> techniques >>>>>>>> like >>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>> m3core, and >>>>>>>> called by Pickle code. >>>>>>>> >>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>> layout >>>>>>>> behavior. There is no shared code. Making it common would >>>>>> involve >>>>>>>> quite a bit of rework, as the two use substantially different >>>>>> data >>>>>>>> structure and code organization. It will be obvious what kind >>>>>> of bit >>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>> >>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>> comparing the >>>>>>>> field displacement computations in RTTipe and in the >>>>>> compiler. The >>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>> >>>>>>>> Note that all this is required even without any packing of >>>>>> small fields >>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>> on a >>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>> >>>>>>>> Tony Hosking wrote: >>>>>>>> >>>>>>>>> Rodney, >>>>>>>>> >>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>> RTPacking? I >>>>>>>>> would have thought all packing is done on word-sized units >>>>>> anyway. >>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>> figure >>>>>>>>> out what to do presumably no differently from the way >>>>>> INTEGER is >>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>> missing >>>>>>>>> something? >>>>>>>>> >>>>>>>>> -- Tony >>>>>>>>> >>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>> help with? >>>>>>>>>> >>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>> >>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>> LONGINT, >>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>> what the native word size can represent. >>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>> recently) >>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>> >>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>> - >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------- >>>>>> 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 rcoleburn at scires.com Tue Feb 19 05:52:26 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 18 Feb 2008 23:52:26 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> Message-ID: <47BA1A35.1E75.00D7.1@scires.com> Sorry, but I've never checked to see how pickles represent "BITS FOR". I've used BITS FOR only on rare occasion. My concern about "breaking" is that if a change is made to the encoding of pickles, then all other programs that use pickles would need to be rebuilt in order to remain compatible. I seem to recall that there is a version number that is put into the encoding to help with compatibility and of course we already have pickle, pickle2, netobj, and netobj2. Perhaps your change could be structured in such a way as to still understand the older variants for compatibility. Here is a scenario: Suppose I have a program that uses pickles and/or netobj. A version is built and put into an embedded system. This system shares pickles/netobj with another client program. After the embedded system is fielded, a change is made to the encoding of pickles. New features are added to the client program and it is rebuilt. Now the client program can't share pickles with the embedded system. Scenario2: A program uses pickles to store data in files. If the pickle structure is changed, the program will no longer be able to read its old files without some sort of transformation function on all the files. Regards, Randy >>> "Darko" 2/18/2008 8:44 PM >>> Actually rather than compilain rather grumpily, maybe I can just make the changes required to RTTipe and do the work to reomve the pragma. I can work with Randy to ensure it doesn't break pickles, there is no reason why it should. On tha subject Randy, I assume pickles encode the number of BITS FOR for a field? If not it should. > We seem to be going through these same point several times. I'm not sure > what the difficulty is, I'm just repeating myself. > > Keep in mind this applies *only* to packed structures, ie BIT FOR or bit > fields. > > The change I put in libralised the *M3* alignment rules so that BITS FOR > fields in structures would align on byte boundries if possible instead of > restricting them to word alignment generally. GCC happily generates code > for this. There may be restrictions in GCC's C as to how you can arrange > bit fields but I don't see what they have to do with M3. > > This is absolutely essentail for using the native APIs on Mac OS X and its > removal would make M3 pointless for use on the Mac, at least more me. > > This should be the default behviour. If you are using BITS FOR it's > becuase you want to arrange the fields in a record in particular way. Why > then arbitrarliy pad out the fields? If performance is an issue, the user > should be using appropriate field bit sizes. The implementation rule for > BITS FOR in M3 is implementation dependent, there are no language issues. > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > created and had nothing to do with me. I diagreed with it and never used > it in the version of the compiler I ran. I support its removal. > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: >> >>> The alignment behaviour is absolutely crucial to programming >>> natively in Mac OS X and should be kept. I have a great need for it. >>> >>> The PRGAMA is of no use and can be removed. >>> >>> Does anyone have any objections to making this alignment behaviour >>> standard? >> >> What do you mean make LAZYALIGN standard? Why wouldn't we go with >> the standard gcc-backend alignment? Perhaps I don't understand what >> it is you are doing or trying to do. Again, please remind me what it >> is that LAZYALIGN does and why it is needed. >> >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>> >>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>> Randy that if it is rarely used and moreso breaks things I would >>>> argue to abandon it. >>>> >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>> >>>>> I use pickles extensively and they are used also by network objects. >>>>> I've never used LAZYALIGN. >>>>> My vote is that we don't break something (pickles/netobj) to add >>>>> support for something that is rarely used. >>>>> Regards, >>>>> Randy >>>>> >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>>> PM >>> >>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>> requiring existing pickle files to be regenerated and/or existing >>>>> code that reads/writes pickles to need recompilation. >>>>> >>>>> Anybody on this list who has code that might be affected if pickles >>>>> or compiled code were invalidated by a change? >>>>> >>>>> I do propose we change the way of telling the compiler to do >>>>> LAZYALIGN so that it is a property of a type and affects all >>>>> variables of that type. >>>>> >>>>> Olaf Wagner wrote: >>>>> > Perhaps we should check-in this description somewhere near the >>>>> > actual code? Or is there enough documentation already? >>>>> > >>>>> > Olaf >>>>> > >>>>> > PS: Based on your description, I'd say we should abandon >>>>> LAZYALIGN. >>>>> > Or at least put a big sticker on that it will break pickles. >>>>> > >>>>> > Quoting "Rodney M. Bates" : >>>>> > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>>> BITSIZE, >>>>> >> etc. only works for getting object layouts as on the machine >>>>> executing >>>>> >> the code, which is all that is needed when writing a pickle. >>>>> >> >>>>> >> When reading, Pickle code needs to know the layouts of a type >>>>> both as >>>>> >> it is on the reading machine and as it was on the machine that >>>>> wrote >>>>> >> the pickle. The type description that the compiler generates is >>>>> >> excerpted and contains no field displacements, just lists of >>>>> field >>>>> >> types (which are either recursive type descriptions or builtin >>>>> types). >>>>> >> So it is independent of word sizes, etc. >>>>> >> >>>>> >> Pickles regenerates the displacements using the few target >>>>> machine >>>>> >> characteristics in a RTPacking.T It traverses a type >>>>> description and >>>>> >> simultaneously computes two sets of field displacements, both >>>>> as they >>>>> >> are on the reading machine and on the writing machine. For >>>>> the latter, >>>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>>> stored in the >>>>> >> header of the pickle file. For the former, it's gotten by >>>>> techniques >>>>> >> like >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>>> m3core, and >>>>> >> called by Pickle code. >>>>> >> >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>>> layout >>>>> >> behavior. There is no shared code. Making it common would >>>>> involve >>>>> >> quite a bit of rework, as the two use substantially different >>>>> data >>>>> >> structure and code organization. It will be obvious what kind >>>>> of bit >>>>> >> damage could occur if the two algorithms didn't agree. >>>>> >> >>>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>>> comparing the >>>>> >> field displacement computations in RTTipe and in the >>>>> compiler. The >>>>> >> former is oblivious to LAZYALIGN. >>>>> >> >>>>> >> Note that all this is required even without any packing of >>>>> small fields >>>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>>> on a >>>>> >> 32-bit machine and unpickled on a 64. >>>>> >> >>>>> >> Tony Hosking wrote: >>>>> >> >>>>> >>> Rodney, >>>>> >>> >>>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>> >>> would have thought all packing is done on word-sized units >>>>> anyway. >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>>> figure >>>>> >>> out what to do presumably no differently from the way >>>>> INTEGER is >>>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>>> >>> something? >>>>> >>> >>>>> >>> -- Tony >>>>> >>> >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>> >>> >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>> help with? >>>>> >>>> >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>> >>>> >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> >>>>> (which can vary independently of the size of INTEGER). >>>>> >>>>> 2) Variable length values of subrange bounds found in type >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> >>>>> what the native word size can represent. >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>> recently) >>>>> >>>>> is not handled by Pickles. >>>>> >>>>> >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>> >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------------------------------------------------------------- >>>>> >>>>> 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 >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> -- >>>>> >> ------------------------------------------------------------- >>>>> >> 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 >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> 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 darko at darko.org Tue Feb 19 11:02:16 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:02:16 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> Message-ID: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> There wouldn't be any explicit expression. in the source, but there would be a flag in Target.i3 for turning it off and on for different platforms. Although the details may be a bit off, the principal is this: before byte alignment change: RECORD a: BITS 8 FOR 0..255; (* takes 32 bits *) b: BITS 32 FOR INTEGER; (* takes 32 bits *) c: BITS 16 FOR 0..65000; (* takes 32 bits *) END; after byte alignment change: RECORD a: BITS 8 FOR 0..255; (* takes 8 bits *) b: BITS 32 FOR INTEGER; (* takes 32 bits *) c: BITS 16 FOR 0..65000; (* takes 16 bits *) END; On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > Thanks for the explanation! How does one express the alignment you > support? > > It does sound like <*LAZYALIGN*> can go away. > > On Feb 18, 2008, at 8:44 PM, Darko wrote: > >> Actually rather than compilain rather grumpily, maybe I can just >> make the >> changes required to RTTipe and do the work to reomve the pragma. I >> can >> work with Randy to ensure it doesn't break pickles, there is no >> reason why >> it should. >> >> On tha subject Randy, I assume pickles encode the number of BITS FOR >> for a field? If not it should. >> >> >>> We seem to be going through these same point several times. I'm >>> not sure >>> what the difficulty is, I'm just repeating myself. >>> >>> Keep in mind this applies *only* to packed structures, ie BIT FOR >>> or bit >>> fields. >>> >>> The change I put in libralised the *M3* alignment rules so that >>> BITS FOR >>> fields in structures would align on byte boundries if possible >>> instead of >>> restricting them to word alignment generally. GCC happily >>> generates code >>> for this. There may be restrictions in GCC's C as to how you can >>> arrange >>> bit fields but I don't see what they have to do with M3. >>> >>> This is absolutely essentail for using the native APIs on Mac OS X >>> and its >>> removal would make M3 pointless for use on the Mac, at least more >>> me. >>> >>> This should be the default behviour. If you are using BITS FOR it's >>> becuase you want to arrange the fields in a record in particular >>> way. Why >>> then arbitrarliy pad out the fields? If performance is an issue, >>> the user >>> should be using appropriate field bit sizes. The implementation >>> rule for >>> BITS FOR in M3 is implementation dependent, there are no language >>> issues. >>> >>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>> created and had nothing to do with me. I diagreed with it and >>> never used >>> it in the version of the compiler I ran. I support its removal. >>> >>> >>> >>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>> >>>>> The alignment behaviour is absolutely crucial to programming >>>>> natively in Mac OS X and should be kept. I have a great need for >>>>> it. >>>>> >>>>> The PRGAMA is of no use and can be removed. >>>>> >>>>> Does anyone have any objections to making this alignment behaviour >>>>> standard? >>>> >>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>> the standard gcc-backend alignment? Perhaps I don't understand >>>> what >>>> it is you are doing or trying to do. Again, please remind me >>>> what it >>>> is that LAZYALIGN does and why it is needed. >>>> >>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>> >>>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>> argue to abandon it. >>>>>> >>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>> >>>>>>> I use pickles extensively and they are used also by network >>>>>>> objects. >>>>>>> I've never used LAZYALIGN. >>>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>>> support for something that is rarely used. >>>>>>> Regards, >>>>>>> Randy >>>>>>> >>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>> PM >>> >>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>> existing >>>>>>> code that reads/writes pickles to need recompilation. >>>>>>> >>>>>>> Anybody on this list who has code that might be affected if >>>>>>> pickles >>>>>>> or compiled code were invalidated by a change? >>>>>>> >>>>>>> I do propose we change the way of telling the compiler to do >>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>> variables of that type. >>>>>>> >>>>>>> Olaf Wagner wrote: >>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>> actual code? Or is there enough documentation already? >>>>>>>> >>>>>>>> Olaf >>>>>>>> >>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>> LAZYALIGN. >>>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>>> >>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>> >>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>> BITSIZE, >>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>> executing >>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>> >>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>> both as >>>>>>>>> it is on the reading machine and as it was on the machine that >>>>>>> wrote >>>>>>>>> the pickle. The type description that the compiler >>>>>>>>> generates is >>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>> field >>>>>>>>> types (which are either recursive type descriptions or builtin >>>>>>> types). >>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>> >>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>> machine >>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>> description and >>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>> as they >>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>> the latter, >>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>> stored in the >>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>> techniques >>>>>>>>> like >>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>> m3core, and >>>>>>>>> called by Pickle code. >>>>>>>>> >>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>> layout >>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>> involve >>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>> data >>>>>>>>> structure and code organization. It will be obvious what kind >>>>>>> of bit >>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>> >>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>> comparing the >>>>>>>>> field displacement computations in RTTipe and in the >>>>>>> compiler. The >>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>> >>>>>>>>> Note that all this is required even without any packing of >>>>>>> small fields >>>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>>> on a >>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>> >>>>>>>>> Tony Hosking wrote: >>>>>>>>> >>>>>>>>>> Rodney, >>>>>>>>>> >>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>> RTPacking? I >>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>> anyway. >>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>> figure >>>>>>>>>> out what to do presumably no differently from the way >>>>>>> INTEGER is >>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>> missing >>>>>>>>>> something? >>>>>>>>>> >>>>>>>>>> -- Tony >>>>>>>>>> >>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>> help with? >>>>>>>>>>> >>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>> >>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>> LONGINT, >>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>> recently) >>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>> >>>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>>> >>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------- >>>>>>> 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 darko at darko.org Tue Feb 19 09:50:38 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 19:50:38 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BA1A35.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <47BA1A35.1E75.00D7.1@scires.com> Message-ID: I agree that pickles should not break. I'm not convinced this alignment change break pickles since it doesn't do anything but change the padding of fields in structures, which is going to change between platforms anyway. Or maybe pickles don't support bit fields anyway. Do pickles use RTTipe exclusively or does it do its own hacking too? On 19/02/2008, at 3:52 PM, Randy Coleburn wrote: > Sorry, but I've never checked to see how pickles represent "BITS FOR". > I've used BITS FOR only on rare occasion. > > My concern about "breaking" is that if a change is made to the > encoding of pickles, then all other programs that use pickles would > need to be rebuilt in order to remain compatible. I seem to recall > that there is a version number that is put into the encoding to help > with compatibility and of course we already have pickle, pickle2, > netobj, and netobj2. Perhaps your change could be structured in > such a way as to still understand the older variants for > compatibility. > > Here is a scenario: Suppose I have a program that uses pickles and/ > or netobj. A version is built and put into an embedded system. > This system shares pickles/netobj with another client program. > After the embedded system is fielded, a change is made to the > encoding of pickles. New features are added to the client program > and it is rebuilt. Now the client program can't share pickles with > the embedded system. > > Scenario2: A program uses pickles to store data in files. If the > pickle structure is changed, the program will no longer be able to > read its old files without some sort of transformation function on > all the files. > > Regards, > Randy > > >>> "Darko" 2/18/2008 8:44 PM >>> > Actually rather than compilain rather grumpily, maybe I can just > make the > changes required to RTTipe and do the work to reomve the pragma. I can > work with Randy to ensure it doesn't break pickles, there is no > reason why > it should. > > On tha subject Randy, I assume pickles encode the number of BITS FOR > for a field? If not it should. > > > > We seem to be going through these same point several times. I'm > not sure > > what the difficulty is, I'm just repeating myself. > > > > Keep in mind this applies *only* to packed structures, ie BIT FOR > or bit > > fields. > > > > The change I put in libralised the *M3* alignment rules so that > BITS FOR > > fields in structures would align on byte boundries if possible > instead of > > restricting them to word alignment generally. GCC happily > generates code > > for this. There may be restrictions in GCC's C as to how you can > arrange > > bit fields but I don't see what they have to do with M3. > > > > This is absolutely essentail for using the native APIs on Mac OS X > and its > > removal would make M3 pointless for use on the Mac, at least more > me. > > > > This should be the default behviour. If you are using BITS FOR it's > > becuase you want to arrange the fields in a record in particular > way. Why > > then arbitrarliy pad out the fields? If performance is an issue, > the user > > should be using appropriate field bit sizes. The implementation > rule for > > BITS FOR in M3 is implementation dependent, there are no language > issues. > > > > The LAZYALIGN pragma (that is, the prgama itself) is something Olaf > > created and had nothing to do with me. I diagreed with it and > never used > > it in the version of the compiler I ran. I support its removal. > > > > > > > >> On Feb 18, 2008, at 3:01 PM, Darko wrote: > >> > >>> The alignment behaviour is absolutely crucial to programming > >>> natively in Mac OS X and should be kept. I have a great need for > it. > >>> > >>> The PRGAMA is of no use and can be removed. > >>> > >>> Does anyone have any objections to making this alignment behaviour > >>> standard? > >> > >> What do you mean make LAZYALIGN standard? Why wouldn't we go with > >> the standard gcc-backend alignment? Perhaps I don't understand > what > >> it is you are doing or trying to do. Again, please remind me > what it > >> is that LAZYALIGN does and why it is needed. > >> > >>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: > >>> > >>>> Can someone remind me again why we need LAZYALIGN? I concur with > >>>> Randy that if it is rarely used and moreso breaks things I would > >>>> argue to abandon it. > >>>> > >>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: > >>>> > >>>>> I use pickles extensively and they are used also by network > objects. > >>>>> I've never used LAZYALIGN. > >>>>> My vote is that we don't break something (pickles/netobj) to add > >>>>> support for something that is rarely used. > >>>>> Regards, > >>>>> Randy > >>>>> > >>>>> >>> "Rodney M. Bates" 2/15/2008 5:06 > >>>>> PM >>> > >>>>> I'll put it in comments in the code. I am sure I can fix it to > >>>>> handle LAZYALIGN too, just not sure whether I can do it without > >>>>> requiring existing pickle files to be regenerated and/or > existing > >>>>> code that reads/writes pickles to need recompilation. > >>>>> > >>>>> Anybody on this list who has code that might be affected if > pickles > >>>>> or compiled code were invalidated by a change? > >>>>> > >>>>> I do propose we change the way of telling the compiler to do > >>>>> LAZYALIGN so that it is a property of a type and affects all > >>>>> variables of that type. > >>>>> > >>>>> Olaf Wagner wrote: > >>>>> > Perhaps we should check-in this description somewhere near the > >>>>> > actual code? Or is there enough documentation already? > >>>>> > > >>>>> > Olaf > >>>>> > > >>>>> > PS: Based on your description, I'd say we should abandon > >>>>> LAZYALIGN. > >>>>> > Or at least put a big sticker on that it will break > pickles. > >>>>> > > >>>>> > Quoting "Rodney M. Bates" : > >>>>> > > >>>>> >> The word "Packing" in RTPacking is perhaps misleading. Using > >>>>> BITSIZE, > >>>>> >> etc. only works for getting object layouts as on the machine > >>>>> executing > >>>>> >> the code, which is all that is needed when writing a pickle. > >>>>> >> > >>>>> >> When reading, Pickle code needs to know the layouts of a type > >>>>> both as > >>>>> >> it is on the reading machine and as it was on the machine > that > >>>>> wrote > >>>>> >> the pickle. The type description that the compiler > generates is > >>>>> >> excerpted and contains no field displacements, just lists of > >>>>> field > >>>>> >> types (which are either recursive type descriptions or > builtin > >>>>> types). > >>>>> >> So it is independent of word sizes, etc. > >>>>> >> > >>>>> >> Pickles regenerates the displacements using the few target > >>>>> machine > >>>>> >> characteristics in a RTPacking.T It traverses a type > >>>>> description and > >>>>> >> simultaneously computes two sets of field displacements, both > >>>>> as they > >>>>> >> are on the reading machine and on the writing machine. For > >>>>> the latter, > >>>>> >> the value of RTPacking.T is (after a compact bit encoding) > >>>>> stored in the > >>>>> >> header of the pickle file. For the former, it's gotten by > >>>>> techniques > >>>>> >> like > >>>>> >> using BITSIZE. This is actually all done in RTTipe, part of > >>>>> m3core, and > >>>>> >> called by Pickle code. > >>>>> >> > >>>>> >> This is very fragile. RTTipe has to duplicate the compiler's > >>>>> layout > >>>>> >> behavior. There is no shared code. Making it common would > >>>>> involve > >>>>> >> quite a bit of rework, as the two use substantially different > >>>>> data > >>>>> >> structure and code organization. It will be obvious what > kind > >>>>> of bit > >>>>> >> damage could occur if the two algorithms didn't agree. > >>>>> >> > >>>>> >> This is why I am obsessing over LAZYALIGN. I have been > >>>>> comparing the > >>>>> >> field displacement computations in RTTipe and in the > >>>>> compiler. The > >>>>> >> former is oblivious to LAZYALIGN. > >>>>> >> > >>>>> >> Note that all this is required even without any packing of > >>>>> small fields > >>>>> >> within words. E.G., a record with two INTEGER fields, > pickled > >>>>> on a > >>>>> >> 32-bit machine and unpickled on a 64. > >>>>> >> > >>>>> >> Tony Hosking wrote: > >>>>> >> > >>>>> >>> Rodney, > >>>>> >>> > >>>>> >>> Why does there need to be an entry for LONGINT in > RTPacking? I > >>>>> >>> would have thought all packing is done on word-sized units > >>>>> anyway. > >>>>> >>> Each side of the connection can check BITSIZE(LONGINT) to > >>>>> figure > >>>>> >>> out what to do presumably no differently from the way > >>>>> INTEGER is > >>>>> >>> communicated between 32-bit and 64-bit machines. Am I > missing > >>>>> >>> something? > >>>>> >>> > >>>>> >>> -- Tony > >>>>> >>> > >>>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >>>>> >>> > >>>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can > >>>>> help with? > >>>>> >>>> > >>>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >>>>> >>>> > >>>>> >>>>> 1) RTPacking.T and needs to have a separate size for > LONGINT, > >>>>> >>>>> (which can vary independently of the size of INTEGER). > >>>>> >>>>> 2) Variable length values of subrange bounds found in type > >>>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond > >>>>> >>>>> what the native word size can represent. > >>>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added > >>>>> recently) > >>>>> >>>>> is not handled by Pickles. > >>>>> >>>>> > >>>>> >>>>> I have done some coding on this, but have been > interrupted. > >>>>> >>>>> > >>>>> >>>>> Tony Hosking wrote: > >>>>> >>>>> > >>>>> >>>>>> Why is LONGINT for pickles not yet supported? > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> -- > >>>>> >>>>> > ------------------------------------------------------------- > >>>>> >>>>> 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 > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >> > >>>>> >> -- > >>>>> >> ------------------------------------------------------------- > >>>>> >> 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 > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> -- > >>>>> ------------------------------------------------------------- > >>>>> 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 darko at darko.org Tue Feb 19 11:04:09 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:04:09 +1100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> I agree that there should be a pre-processor between M3 syntax and C syntax, but this should also be integrated into the build system so that it is transparent. I think the '.mc' extension is already taken though, which is a bummer. I think we should also be aiming to use this tool to automatically convert C header files (with limitations) to M3. The more I think about it the more I wonder if C programers will swallow it: for example VAR params? Further comments are embedded... On 18/02/2008, at 3:26 PM, Jay wrote: > I've been trying to stay out of this... I would have though your input was most appropriate since your a member of the target audience. > If a comment at the top of the file can make the Modula-3 syntax > more like C then.. Not really what we're aiming for. We're looking for a separate C like syntax in separate files. > replace = with == yes > replace := with = yes > make assignment an expression no, that changes the abstract syntax, which is something we're trying to avoid. > lowercase the keywords yes > try to make braces work (with some alteration for C) yes > use type name instead of name : type yes > separate function parameters with commas and require each to state > its type yes > for that matter, subset C and require all declarations be separate > like that? Do you think C programmers would object? > put back ++, --, -=, +=, etc. yes > superset C and let . be used in place of -> yes > new coding style is four space indent with opening braces on their > own line :) I don't do that even in C > Hm. I think if anyone really wants to do this, instead of nit > picking about Modula-3 syntax here and there, go about it in a > slightly different way? We're really not looking to change M3 in any way, just provide an alternate syntax. > Pick apart what defines Modula-3 through much discussion. > Optional safety -- probably but that for these purposes > optional garbage collection -- maybe that too > "object orientation" that is a subset of C++ > try to use C++ syntax? > generics (generic modules) > independently and relatively easily parsable interface definitions > (!) > these are both important, but I think "independent" is more > important > and "relatively easily" could be omitted for the goals of this > exercise > compiles to native code > sizeof(integer) == sizeof(address) (minor detail) > built in sets and good enumerations > arrays; I don't like them starting at non-zero, but enums for their > index are interesting > > Take the existing definition of C and alter it to have these > characteristics very very much like Modula-3 but with very very very > much Modula-3 syntax From darko at darko.org Tue Feb 19 11:32:22 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 21:32:22 +1100 Subject: [M3devel] ARM_DARWIN? Message-ID: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> I'm interested in targeting Darwin on the ARM processor, to allow software development for Apple touchscreen hardware such as the iPhone and the iPod touch. Is anyone else interested in this? I know there has been some work by others (see posts here by Iztok Kobal) on targeting processors in the ARM family. The hardware mentioned definitely runs Darwin, or something very much like it. Apparently the CPU is an ARM 11 on the iPhone. Apple is due to release an SDK shortly that will almost certainly mean there will be an ARM target in the standard (XCode) toolchain so it should be a matter of adapting Apple's back end as distributed. It would have to be a cross compiler since being hosted on the target hardware isn't very practical. I'd be very interested to hear from anyone with an interest in this platform. Regards, Darko. From jayk123 at hotmail.com Tue Feb 19 15:34:55 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 19 Feb 2008 14:34:55 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: > I would have though your input was most appropriate since your a I thought I was mostly just pissing people off.> > make assignment an expression> > no, that changes the abstract syntax, which is something we're trying > to avoid. Well.. are there no transforms allowed? Or, no growth of the abstract syntax and Modula-3 doesn't necessarily generate every node type, nor maybe does Modula-C generate every node type, but union them? For example version 1 of Modula-C probably doesn't have "objects", and maybe always unsafe, no optional safety? Though, granted, enabling you to state everything in Modula-C that you can state in Modula-3 is probably important. You don't want people chosing one or the other based on needing certain features, only based on taste. (Someone else said "Codula-3". :)) I guess maybe a more important useful angle here is the interop with C headers. VAR parameters..are roughly just pointers, ok. Or like C++ references. btw, while we are on the subject..I like C's looping constructs, the three expression for loop, do, while, break, continue. Is "exit" what I use in Modula-3 for break? I've been writing loops that could terminate once they find something but have to look this up, otherwise have been letting the loop run longer than necessary..which I saw existing code do anyway. - Jay > CC: wagner at elegosoft.com; m3devel at elegosoft.com> From: darko at darko.org> To: jayk123 at hotmail.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> Date: Tue, 19 Feb 2008 21:04:09 +1100> > I agree that there should be a pre-processor between M3 syntax and C > syntax, but this should also be integrated into the build system so > that it is transparent. I think the '.mc' extension is already taken > though, which is a bummer.> > I think we should also be aiming to use this tool to automatically > convert C header files (with limitations) to M3.> > The more I think about it the more I wonder if C programers will > swallow it: for example VAR params?> > Further comments are embedded...> > On 18/02/2008, at 3:26 PM, Jay wrote:> > I've been trying to stay out of this...> > I would have though your input was most appropriate since your a > member of the target audience.> > > If a comment at the top of the file can make the Modula-3 syntax > > more like C then..> > Not really what we're aiming for. We're looking for a separate C like > syntax in separate files.> > > replace = with ==> > yes> > > replace := with => > yes> > > make assignment an expression> > no, that changes the abstract syntax, which is something we're trying > to avoid.> > > lowercase the keywords> > yes> > > try to make braces work (with some alteration for C)> > yes> > > use type name instead of name : type> > yes> > > separate function parameters with commas and require each to state > > its type> > yes> > > for that matter, subset C and require all declarations be separate > > like that?> > Do you think C programmers would object?> > > put back ++, --, -=, +=, etc.> > yes> > > superset C and let . be used in place of ->> > yes> > > new coding style is four space indent with opening braces on their > > own line :)> > I don't do that even in C> > > Hm. I think if anyone really wants to do this, instead of nit > > picking about Modula-3 syntax here and there, go about it in a > > slightly different way?> > We're really not looking to change M3 in any way, just provide an > alternate syntax.> > > > Pick apart what defines Modula-3 through much discussion.> > Optional safety -- probably but that for these purposes> > optional garbage collection -- maybe that too> > "object orientation" that is a subset of C++> > try to use C++ syntax?> > generics (generic modules)> > independently and relatively easily parsable interface definitions > > (!)> > these are both important, but I think "independent" is more > > important> > and "relatively easily" could be omitted for the goals of this > > exercise> > compiles to native code> > sizeof(integer) == sizeof(address) (minor detail)> > built in sets and good enumerations> > arrays; I don't like them starting at non-zero, but enums for their > > index are interesting> >> > Take the existing definition of C and alter it to have these > > characteristics very very much like Modula-3 but with very very very > > much Modula-3 syntax> > > > > > _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 19 15:39:37 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 19 Feb 2008 14:39:37 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200802182204.m1IM47eI037784@camembert.async.caltech.edu> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: I have some ideas here that I am pretty certain WILL be acceptable. But I'd like to know if the current behavior really isn't. The ideas are: 1) (* A well designed approach might look like this, however how do we determine the target behavior? Seps_t = RECORD (* Whenever a character must be "written", DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep : CHAR; DirSepText : TEXT; END; SepKind_t = { Unix, Win, Winx }; CONST Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; *) and then I think m3middle would have to specify the behavior of each target -- of course most are "Unix". 2) less work for now, very much like the current behavior, except Colon changes from CONST to VAR and is ':' if the environment variable OS == "Windows_NT", else '\000'. The support for backslashes could key off this too, though I believe it is FAR less controversial. Also, I want to move m3path.m3 into a lower layer so it useable a little more. Like into m3quake (QPath?) or m3middle (M3Path?). However I worry about the effect on source control history. Advise? For now I've got one path function in one m3quake file, another path function in another m3quake file, and everything else remaining in cm3/src/M3Path.m3. - Jay From: jayk123 at hotmail.comTo: mika at async.caltech.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 18 Feb 2008 22:27:56 +0000 I'm going to work on this more but not today.I will at least restrict it to check that the next character is a slash.I'm not sure that will satisfy folks.The Pathname module is/was being used but is a little unsatisfactory. > I use colons in filenames a lot Do you use it in source files?For "root" directories, like where your cm3 install/source is? I'm trying to think/wiggle through what might be an acceptable escape.Something like -- where files in general are vs. where "programmer" files are.Putting a colon in a filename really is quite non-portable.And that may or may not matter. The existing Modula-3 code was fairly strict and I very unsure it was right.I had a question drafted to m3devel that I ended up not sending.It went roughly like:" Has anyone done a cross build where host and target vary in naming conventions? I am skeptical that this works, and am strongly considering /slightly/ depending on that or making it "worse". In particular, there is provision in the code for "converting" between host and target paths, but all it does is translate slashes. It doesn't translate libfoo.a to foo.lib for example." Upon further digging though, I decide that my more immediate severe problemcould be dealt with not by making things worse but by making them better.This is the change around checking NAMING_CONVENTIONS earlier.While my analysis was not 100% thorough, it is my very strong suspicionthat the NAMING_CONVENTION and undocumented TARGET_NAMING configurationvariables never really worked. Sure, they affected the name of the .m3x file.But that is about it. I didn't check .exes, but probably didn't work, and what I wasseeing was they didn't work for libraries. M3Path.m3 sets up one set of path data in three ways. variable initialization (VAR foo := 123) module initialization (BEGIN foo := 456 END Module.) and explicit calls after reading the config file The problem was that the explicit calls were very late, so the module initialization is what held.If Join(a,b) == a/b, then you'd get Unix naming conventions./Arguably/ this is exactly correct.But I would like the slash and the "naming" to be separate, at least for now.That is, NT386GNU uses forward slashes but foo.lib instead of libfoo.a.I should try to change that actually.I had trouble changing it for this reason since I was cross building from NT386. The NT386 HOST wants to use Win32 naming conventions, "\" and foo.lib, evenif the config file asks for Unix naming.. Anyway, this is all somewhat of a tangent, one in which I'm more confident of where to go and that what I changed is ok. (It might become irrelevant.) The other issues are around "difficulty" setting paths.I had CM3_ROOT=c:\dev2\cm3.2.That wouldn't necessarily work with NT386GNU. It seems darn near possible to have one path syntax and one set of code for dealing with it.But maybe not.Even semicolon vs. colon seems doable. Specifically, if an element of $PATH appears to be just a single character, that colon is not a $PATH divider. Perhaps I just need to have two sets of CM3_ROOT / CM3_INSTALL and perhaps M3CONFIG variables.I was kind of hoping not. It's worse than that really, since the two hosts can target the two targets, so host and target paths needs to be better distinguished than I believe the are now. I was saying there is code to change the slashes, but there isn't code to deal with a leading drive letter. What I have been particularly avoiding is calls out to cygwin_convert_path or such, but maybe that's what I need to do. Get ROOT / CM3_INSTALL etc. from the command line and environment, convert as appropriate, and move on. ROOT in particular is set by Python. Usually for me that is Win32 Python, but Cygwin Python is an option.So then Python has to know what cm3 it is running?I considered probing it with findstr /i /m cm3.exe cygwin1.dll.I considered something like cm3 -report_something_or_other, kind of like gcc has -print-gcc-lib-name or whatnot. These might still be viable ideas. Historically cross environments don't allow multiple "targets" / "platforms" / "configurations" / "whatever" to run on the same OS. But there is some of an opposite trend. Like how NT386 and NT386GNU run on the same OS. Like SOLsun, SOLgnu. Like x86 on AMD64 operating systems. So maybe a little bit of support is good there, the cm3 -print-slash or cm3 -print-host or something. Also I forgot to point out that Win32 is often find with forward slashes, but notable file.open dialogs are not.I very frequently copy compiler output to file.open dialogs so in some places backward slashes are preferred.A possible strategy is to sniff what the user is using -- such as in any of those environment variables -- and favor it.Or for each Join operating harvest a path separater from the parameters and default if there is none there. I have some code working like that last option right now but it's not quite working and has to wait. It is very reasonable to have Win32 treat forward and backward slashes as the same, in particular.It is fairly reasonable imho for Posix code to also treat them the same but "fixup" backward to forward. As well, on Windows, if you mostly limit yourself to one drive letter, then /foo/bar is a pretty acceptable form.. Anyway...lots of facts, some easy conclusions, some unclear conclusions.I'll fiddle around with it more later.Ideally switching between NT386 and NT386GNU is fairly easy.. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 18 Feb 2008 14:04:06 -0800> From: mika at async.caltech.edu> > > I never tried putting it in my PATH, no... You are right, colons> are *slightly* special. I am not in the habit of copying files to> Windows. I only copy files between Unix and Windows to save them> from Windows.> > That being said, I am pretty sure I use colons more in filenames> than I use the letter "q". Could you ban the letter "q" instead? :)> > If you've gotta do it, then do it. It's just ... weird.> > I personally will probably never run into the issue. I use colons> in filenames a lot, but as a separator for various types of data> files. :.> > Is your code able to import (or duplicate...) Pathname? I would> have thought that that interface has all the necessary bits to make> paths portable...> > MIka> > Jay writes:> >--_dfd4e29a-b904-43be-8435-4824d419d270_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> But colons? Colons are not special in any way, shape, or form, on> Unix..=> >. I think "it is extremely surprising" to a Unix user if a path> >Ever try putting a path with a colon into $PATH? Does it work?> >Or copying a file with a colon in its name to a Windows system? Does it wor=> >k?> >This part could be limited to systems that have $OS =3D=3D Windows_NT I gue=> >ss.> >=20> >As a user switching between multiple systems, this area is quite frustratin=> >g...I guess no matter what.> >Sometimes one form works, sometimes another, sometimes either, often with i=> >dentical meaning, but not always.> >These changes, and about one more, should make building NT386GNU a fair amo=> >unt easier..> >=20> >Currently it is any path with a colon in the second character.> >How about if that is further restricted to having a-z in the first characte=> >r and/or more importantly a slash in the third character?> >=20> > - Jay> >> >> > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 19 18:31:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 19 Feb 2008 12:31:23 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> Message-ID: <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> I get an error: "../src/Main.m3", line 6: Could not find a legal alignment for the packed type. for the type: TYPE T = RECORD a: BITS 8 FOR [0..255]; c: BITS 16 FOR [0..65535]; b: BITS 32 FOR INTEGER; END; Are you saying that lazy alignment permits this to compile? This is very scary! What happens if you write the following? TYPE T = RECORD a: BITS 8 FOR [0..255]; c: BITS 16 FOR [0..65535]; b: BITS 32 FOR ROOT; END; Now b is a *hidden* reference (because it is unaligned) that the garbage collector will not find if T describes a stack variable t: PROCEDURE p (x: ROOT) = VAR t: T; BEGIN t.b := x; x := NIL; ... garbage collector runs and moves object referred to by t.b but doesn't find t.b reference in stack! t.b^ causes chaos and destruction... END p; Thus, lazy alignment should only be permitted in UNSAFE modules. I hope that this is the case! On Feb 19, 2008, at 5:02 AM, Darko wrote: > There wouldn't be any explicit expression. in the source, but there > would be a flag in Target.i3 for turning it off and on for > different platforms. > > Although the details may be a bit off, the principal is this: > > before byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 32 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 32 bits *) > END; > > after byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 8 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 16 bits *) > END; > > > On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > >> Thanks for the explanation! How does one express the alignment >> you support? >> >> It does sound like <*LAZYALIGN*> can go away. >> >> On Feb 18, 2008, at 8:44 PM, Darko wrote: >> >>> Actually rather than compilain rather grumpily, maybe I can just >>> make the >>> changes required to RTTipe and do the work to reomve the pragma. >>> I can >>> work with Randy to ensure it doesn't break pickles, there is no >>> reason why >>> it should. >>> >>> On tha subject Randy, I assume pickles encode the number of BITS FOR >>> for a field? If not it should. >>> >>> >>>> We seem to be going through these same point several times. I'm >>>> not sure >>>> what the difficulty is, I'm just repeating myself. >>>> >>>> Keep in mind this applies *only* to packed structures, ie BIT >>>> FOR or bit >>>> fields. >>>> >>>> The change I put in libralised the *M3* alignment rules so that >>>> BITS FOR >>>> fields in structures would align on byte boundries if possible >>>> instead of >>>> restricting them to word alignment generally. GCC happily >>>> generates code >>>> for this. There may be restrictions in GCC's C as to how you can >>>> arrange >>>> bit fields but I don't see what they have to do with M3. >>>> >>>> This is absolutely essentail for using the native APIs on Mac OS >>>> X and its >>>> removal would make M3 pointless for use on the Mac, at least >>>> more me. >>>> >>>> This should be the default behviour. If you are using BITS FOR it's >>>> becuase you want to arrange the fields in a record in particular >>>> way. Why >>>> then arbitrarliy pad out the fields? If performance is an issue, >>>> the user >>>> should be using appropriate field bit sizes. The implementation >>>> rule for >>>> BITS FOR in M3 is implementation dependent, there are no >>>> language issues. >>>> >>>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>>> created and had nothing to do with me. I diagreed with it and >>>> never used >>>> it in the version of the compiler I ran. I support its removal. >>>> >>>> >>>> >>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>> >>>>>> The alignment behaviour is absolutely crucial to programming >>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>> for it. >>>>>> >>>>>> The PRGAMA is of no use and can be removed. >>>>>> >>>>>> Does anyone have any objections to making this alignment >>>>>> behaviour >>>>>> standard? >>>>> >>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>>> the standard gcc-backend alignment? Perhaps I don't understand >>>>> what >>>>> it is you are doing or trying to do. Again, please remind me >>>>> what it >>>>> is that LAZYALIGN does and why it is needed. >>>>> >>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>> >>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>> with >>>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>>> argue to abandon it. >>>>>>> >>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>> >>>>>>>> I use pickles extensively and they are used also by network >>>>>>>> objects. >>>>>>>> I've never used LAZYALIGN. >>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>> add >>>>>>>> support for something that is rarely used. >>>>>>>> Regards, >>>>>>>> Randy >>>>>>>> >>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>> PM >>> >>>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>> without >>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>> existing >>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>> >>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>> pickles >>>>>>>> or compiled code were invalidated by a change? >>>>>>>> >>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>> variables of that type. >>>>>>>> >>>>>>>> Olaf Wagner wrote: >>>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>> LAZYALIGN. >>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>> pickles. >>>>>>>>> >>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>> >>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>>> BITSIZE, >>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>> executing >>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>> >>>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>>> both as >>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>> that >>>>>>>> wrote >>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>> generates is >>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>> field >>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>> builtin >>>>>>>> types). >>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>> >>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>> machine >>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>> description and >>>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>>> as they >>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>> the latter, >>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>> stored in the >>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>> techniques >>>>>>>>>> like >>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>> m3core, and >>>>>>>>>> called by Pickle code. >>>>>>>>>> >>>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>>> layout >>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>> involve >>>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>>> data >>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>> kind >>>>>>>> of bit >>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>> >>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>> comparing the >>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>> compiler. The >>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>> >>>>>>>>>> Note that all this is required even without any packing of >>>>>>>> small fields >>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>> pickled >>>>>>>> on a >>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>> >>>>>>>>>> Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Rodney, >>>>>>>>>>> >>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>> RTPacking? I >>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>> anyway. >>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>> figure >>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>> INTEGER is >>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>> missing >>>>>>>>>>> something? >>>>>>>>>>> >>>>>>>>>>> -- Tony >>>>>>>>>>> >>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>>> help with? >>>>>>>>>>>> >>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>> recently) >>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>> >>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>> interrupted. >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> ---------------------------------------------------------- >>>>>>>>>>>>> --- >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 darko at darko.org Tue Feb 19 21:23:23 2008 From: darko at darko.org (Darko) Date: Wed, 20 Feb 2008 07:23:23 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <2AA0698B-53D6-4CA7-A645-0570DBF7586E@cs.purdue.edu> Message-ID: Thanks for raising a very good point. I'd say make it that traced references will not be non-word aligned as a part of the alignment behaviour. On 20/02/2008, at 4:31 AM, Tony Hosking wrote: > I get an error: > > "../src/Main.m3", line 6: Could not find a legal alignment for the > packed type. > > for the type: > > TYPE > T = RECORD > a: BITS 8 FOR [0..255]; > c: BITS 16 FOR [0..65535]; > b: BITS 32 FOR INTEGER; > END; > > Are you saying that lazy alignment permits this to compile? > > > This is very scary! What happens if you write the following? > > TYPE > T = RECORD > a: BITS 8 FOR [0..255]; > c: BITS 16 FOR [0..65535]; > b: BITS 32 FOR ROOT; > END; > > Now b is a *hidden* reference (because it is unaligned) that the > garbage collector will not find if T describes a stack variable t: > > PROCEDURE p (x: ROOT) = > VAR t: T; > BEGIN > t.b := x; > x := NIL; > ... > garbage collector runs and moves object referred to by t.b but > doesn't find t.b reference in stack! > t.b^ causes chaos and destruction... > END p; > > Thus, lazy alignment should only be permitted in UNSAFE modules. I > hope that this is the case! > > On Feb 19, 2008, at 5:02 AM, Darko wrote: > >> There wouldn't be any explicit expression. in the source, but there >> would be a flag in Target.i3 for turning it off and on for >> different platforms. >> >> Although the details may be a bit off, the principal is this: >> >> before byte alignment change: >> >> RECORD >> a: BITS 8 FOR 0..255; (* takes 32 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >> END; >> >> after byte alignment change: >> >> RECORD >> a: BITS 8 FOR 0..255; (* takes 8 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >> END; >> >> >> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >> >>> Thanks for the explanation! How does one express the alignment >>> you support? >>> >>> It does sound like <*LAZYALIGN*> can go away. >>> >>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>> >>>> Actually rather than compilain rather grumpily, maybe I can just >>>> make the >>>> changes required to RTTipe and do the work to reomve the pragma. >>>> I can >>>> work with Randy to ensure it doesn't break pickles, there is no >>>> reason why >>>> it should. >>>> >>>> On tha subject Randy, I assume pickles encode the number of BITS >>>> FOR >>>> for a field? If not it should. >>>> >>>> >>>>> We seem to be going through these same point several times. I'm >>>>> not sure >>>>> what the difficulty is, I'm just repeating myself. >>>>> >>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>> FOR or bit >>>>> fields. >>>>> >>>>> The change I put in libralised the *M3* alignment rules so that >>>>> BITS FOR >>>>> fields in structures would align on byte boundries if possible >>>>> instead of >>>>> restricting them to word alignment generally. GCC happily >>>>> generates code >>>>> for this. There may be restrictions in GCC's C as to how you can >>>>> arrange >>>>> bit fields but I don't see what they have to do with M3. >>>>> >>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>> X and its >>>>> removal would make M3 pointless for use on the Mac, at least >>>>> more me. >>>>> >>>>> This should be the default behviour. If you are using BITS FOR >>>>> it's >>>>> becuase you want to arrange the fields in a record in particular >>>>> way. Why >>>>> then arbitrarliy pad out the fields? If performance is an issue, >>>>> the user >>>>> should be using appropriate field bit sizes. The implementation >>>>> rule for >>>>> BITS FOR in M3 is implementation dependent, there are no >>>>> language issues. >>>>> >>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>> Olaf >>>>> created and had nothing to do with me. I diagreed with it and >>>>> never used >>>>> it in the version of the compiler I ran. I support its removal. >>>>> >>>>> >>>>> >>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>> >>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>> for it. >>>>>>> >>>>>>> The PRGAMA is of no use and can be removed. >>>>>>> >>>>>>> Does anyone have any objections to making this alignment >>>>>>> behaviour >>>>>>> standard? >>>>>> >>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>> with >>>>>> the standard gcc-backend alignment? Perhaps I don't understand >>>>>> what >>>>>> it is you are doing or trying to do. Again, please remind me >>>>>> what it >>>>>> is that LAZYALIGN does and why it is needed. >>>>>> >>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>> >>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>> with >>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>> would >>>>>>>> argue to abandon it. >>>>>>>> >>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>> >>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>> objects. >>>>>>>>> I've never used LAZYALIGN. >>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>> add >>>>>>>>> support for something that is rarely used. >>>>>>>>> Regards, >>>>>>>>> Randy >>>>>>>>> >>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>> PM >>> >>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>> to >>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>> without >>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>> existing >>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>> >>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>> >>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>> variables of that type. >>>>>>>>> >>>>>>>>> Olaf Wagner wrote: >>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>> the >>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>> LAZYALIGN. >>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>> pickles. >>>>>>>>>> >>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>> >>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>> Using >>>>>>>>> BITSIZE, >>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>> executing >>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>> >>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>> type >>>>>>>>> both as >>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>> that >>>>>>>>> wrote >>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>> generates is >>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>> field >>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>> builtin >>>>>>>>> types). >>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>> >>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>> machine >>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>> description and >>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>> both >>>>>>>>> as they >>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>> the latter, >>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>> stored in the >>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>> techniques >>>>>>>>>>> like >>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>> m3core, and >>>>>>>>>>> called by Pickle code. >>>>>>>>>>> >>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>> compiler's >>>>>>>>> layout >>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>> involve >>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>> different >>>>>>>>> data >>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>> kind >>>>>>>>> of bit >>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>> >>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>> comparing the >>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>> compiler. The >>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>> >>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>> small fields >>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>> pickled >>>>>>>>> on a >>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Rodney, >>>>>>>>>>>> >>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>> RTPacking? I >>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>> anyway. >>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>> figure >>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>> INTEGER is >>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>> missing >>>>>>>>>>>> something? >>>>>>>>>>>> >>>>>>>>>>>> -- Tony >>>>>>>>>>>> >>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>> can >>>>>>>>> help with? >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>> type >>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>> recently) >>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 Feb 21 11:42:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 11:42:25 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> Message-ID: <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Quoting Jay : > I have some ideas here that I am pretty certain WILL be acceptable. > But I'd like to know if the current behavior really isn't. > > The ideas are: > 1) > (* A well designed approach might look like this, however how do > we determine the target behavior? > Seps_t = RECORD (* Whenever a character must be "written", > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > : CHAR; DirSepText : TEXT; END; > SepKind_t = { Unix, Win, Winx }; > > CONST > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; > *) > and then I think m3middle would have to specify the behavior of each > target -- of course most are "Unix". > > 2) less work for now, very much like the current behavior, except > Colon changes from CONST to VAR and is ':' if the environment > variable OS == "Windows_NT", else '\000'. The support for > backslashes could key off this too, though I believe it is FAR less > controversial. > > Also, I want to move m3path.m3 into a lower layer so it useable a > little more. > Like into m3quake (QPath?) or m3middle (M3Path?). > > However I worry about the effect on source control history. > Advise? > > For now I've got one path function in one m3quake file, another path > function in another m3quake file, and everything else remaining in > cm3/src/M3Path.m3. I agree that we should have one central abstraction of the pathanme type. What about pushing it further into libm3/.../Pathname? This would need carefully checking of compatibility of course. Also I wouldn't like to see variables exposed in such a module; we should use functions or procedures for everything there. Do you see any problem in providing such a globally unique and compatible abstraction? Could you provide a complete (documented) Pathname module that could be discussed on this list and tested by everybody interested? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 11:55:05 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 21 Feb 2008 02:55:05 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Mon, 18 Feb 2008 23:52:26 EST." <47BA1A35.1E75.00D7.1@scires.com> Message-ID: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> Ugh!!! I am still using compilers that are almost ten years old on ALL my systems just because I need to share pickles between them and CM3 has a different TEXT format from my ancient PM3. Tony thinks there's a workaround with specials but I haven't had a chance to get to it yet... "Randy Coleburn" writes: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=__Part6F499F9A.2__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Sorry, but I've never checked to see how pickles represent "BITS FOR". >I've used BITS FOR only on rare occasion. >=20 >My concern about "breaking" is that if a change is made to the encoding of = >pickles, then all other programs that use pickles would need to be rebuilt = >in order to remain compatible. I seem to recall that there is a version = >number that is put into the encoding to help with compatibility and of = >course we already have pickle, pickle2, netobj, and netobj2. Perhaps your = >change could be structured in such a way as to still understand the older = >variants for compatibility. >=20 >Here is a scenario: Suppose I have a program that uses pickles and/or = >netobj. A version is built and put into an embedded system. This system = >shares pickles/netobj with another client program. After the embedded = >system is fielded, a change is made to the encoding of pickles. New = >features are added to the client program and it is rebuilt. Now the = >client program can't share pickles with the embedded system. >=20 >Scenario2: A program uses pickles to store data in files. If the pickle = >structure is changed, the program will no longer be able to read its old = >files without some sort of transformation function on all the files. >=20 >Regards, >Randy From lemming at henning-thielemann.de Thu Feb 21 13:22:50 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Feb 2008 13:22:50 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: On Tue, 19 Feb 2008, Darko wrote: > I agree that there should be a pre-processor between M3 syntax and C > syntax, but this should also be integrated into the build system so > that it is transparent. I think the '.mc' extension is already taken > though, which is a bummer. > > I think we should also be aiming to use this tool to automatically > convert C header files (with limitations) to M3. You won't be happy with such conversions. The results of translations with SWIG using manual annotations are better, but you quickly run into writing more annotation than converting the C header manually. From darko at darko.org Thu Feb 21 13:48:17 2008 From: darko at darko.org (Darko) Date: Thu, 21 Feb 2008 23:48:17 +1100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: I find converting C headers manually not too bad using a few standard regexes and a couple of rules of thumb. I was hoping something like this could be done with exceptions handled manually. I don't think complete automatic conversion is practical as you say, but there must be something better and more productive than manual conversions. On 21/02/2008, at 11:22 PM, Henning Thielemann wrote: > > On Tue, 19 Feb 2008, Darko wrote: > >> I agree that there should be a pre-processor between M3 syntax and C >> syntax, but this should also be integrated into the build system so >> that it is transparent. I think the '.mc' extension is already taken >> though, which is a bummer. >> >> I think we should also be aiming to use this tool to automatically >> convert C header files (with limitations) to M3. > > You won't be happy with such conversions. The results of > translations with > SWIG using manual annotations are better, but you quickly run into > writing > more annotation than converting the C header manually. From jayk123 at hotmail.com Thu Feb 21 13:56:34 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 21 Feb 2008 12:56:34 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: "Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix. And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong. That is, "cleanup" of a/./b to a/b, a/../b to b. Incorrect in the face of links. But still general purpose if people want it. The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target". This is specially just changing slashes around. It does not deal with "drive letters". It deals with "file types". This is an area that probably does not belong in libm3. "types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib. There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix. Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward. It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data. As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo but when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Feb 21 14:39:21 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Feb 2008 14:39:21 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> <6CE6D44B-9C61-436F-BBE6-86D69033B9C1@darko.org> Message-ID: On Thu, 21 Feb 2008, Darko wrote: > I find converting C headers manually not too bad using a few standard > regexes and a couple of rules of thumb. I was hoping something like > this could be done with exceptions handled manually. I don't think > complete automatic conversion is practical as you say, but there must > be something better and more productive than manual conversions. You can try to improve the attempts I contributed to SWIG. From dragisha at m3w.org Thu Feb 21 17:08:04 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 21 Feb 2008 17:08:04 +0100 Subject: [M3devel] Building minimal and fresh cm3... Message-ID: <1203610084.11244.14.camel@hias.m3w.org> I am trying to make minimal binary rpm for latest cm3. I am creating it's contents with: *** copied and edited cm3.cfg for new root. Set M3CONFIG to point to it. *** copied cm3cg into new .../bin (Do I need ONLY these three files for bootstrap only??? cm3, cm3cg and cm3.cfg) *** checked out yesterday's head *** did ./scripts/do-cm3-std.sh buildship At this moment, I would like to bootstrap new compiler. I see there's "sysutils" package now, so probably I have to modify former list of packages, and I did it so I typed: *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; cm3 -ship) All went well, except I had to add m3objfile (and later m3back) because of: "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/m3makefile", line 24: quake runtime error: unable to open "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading I supposse I also have to build m3cc so I have latest cm3cg? *** did ./scripts/do-cm3-std.sh buildship so all is build with latest cm3. Is this all I need to have brand new hierarchy I can pack into rpm and distribute? dd -- Dragi?a Duri? From wagner at elegosoft.com Thu Feb 21 17:48:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 17:48:30 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> Quoting Jay : > I'd like to make "progress" on what I have -- mainly slash > independence, no colon hack on Unix. > And then see about making much more progress. OK. > M3Path compromises a few bits of functionality, some of which could > go in libm3, but not all. > > It has "path cleanup", of a sort that was strongly suggested here to > be wrong. > That is, "cleanup" of a/./b to a/b, a/../b to b. > Incorrect in the face of links. > But still general purpose if people want it. > The code that does this work I think can stand a rewrite. It is > currently limited to 31 slashes and after that it just silently > ignores stuff. If you reverse the path first, do the work, reverse > again, you can support unlimited lengths with small fixed memory > (smaller than it currently uses to support limit lengths). > > It has "path conversion" between "host" and "target". > This is specially just changing slashes around. > It does not deal with "drive letters". I see. This could be abstracted, too, though. > It deals with "file types". > This is an area that probably does not belong in libm3. > "types" are, you know, .m3, .i3, reasonably simple, but also > libfoo.a vs. foo.lib. > There is code to pick apart paths to "in that way", which I find..a > little unusual. OK. This is rather compiler specific. > I did already change the Win32 Pathname implementation to > always/usually treat forward and backward slashes as the same. That > goes pretty far. > > I believe the Pathname abstraction is that a path is essentially an > array of strings, you can add/remove from either end, add to one or > the other or both ends, and join two. Yes, but it could be extended. There is also some support for different kinds of `roots'. > An issue I'm avoiding..because I don't want to pollute the code with > calls out ot Cygwin, is "correct" conversion between Win32 and > Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. > > I haven't seen how "network paths" are handled. > > Path handling is a surprisingly large rats nest of subtle behaviors > and I'm not sure I really want to open it. I'll second that. > Really, there are a few Win32 behaviors that i haven't gotten into.. > > Even if you ignore Win32 -- what about case sensitivity? Even on Mac > and presumably Unix (to a Mac or Windows server), you can encounter > case insensitive file systems. The current Modula-3 code is not > prepared for that. Case sensitivity of file names should be handled centrally, too. It could be a property of a filename. But then that property needs to be set by someone - runtime, environment, user, application... As this is a big issue for portability of code, I'd say we should come up with some sound concept here, but of course that can be independent of your current work. > One of my favorite sob stories here, I've probably told it here, is > that I have a low end NAS (it won't boot lately..). It runs Linux, > of course (I said it is low end). I downloaded it source, extracted > it, xcopied, xcopyied it again incrementally. That fails. Because > some of the file names start with a dot and on Unix, that means they > are hidden and cannot be unhidden.. `Hidden' on Unix usually only means that files are not shown with a simple `ls'. There's nothing special in the system to treat dot-files different from others as far as I know. > So this whole "hidden" thing is not portable, just as colons in > paths are not portable, but they work just fine if you stay on one > system... > Let me get M3Path to where I want it, and repair the Unix colon > behavior, and see about rewriting the "cleanup" code... as long as > folks are happy with how it ends up, I'm not sure I want to puruse > it much more. There are much bigger fish... OK, I can understand that you just want to finishd your current work. > Oh, I already have code on my system so that when we read ROOT, > CM3_INSTALL, CM3_ROOT from the command line and/or environment, > those paths get "fixed up" -- slashes reversed. That should help a > lot here, without much pollution.. It should help, but it also needs to be tested on different platforms. > One thing I'm not sure about is the treatment of backward slashes > equivalent to forward slashes on Posix. > Maybe better just to do that fixup upon a few certain inputs. And > have Win32 use either, but Posix only forward. > It's "harmless" but loose. Yes, I'd be rather conservative there, too. > There this general problem of "user input" vs. "internal, strongly > typed, analyzed, rule-following" data. > As well as then presenting the internal data back to the user in the > form he expected. > > It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo > but when an error message is reported, in case I am going to > copy/paste the paths in it to file.open, it should be back with > backward slashes. This is not simple. You could maintain two > parallel representations as you muck with the path. Not great. You > could "characterize" the form of the user in put (which slash > directory), keep that around, it's just one bit, and use it to guide > the later presentation... One internal, abstract representation of the data, and two or more views on it (getPosixPath, getWindowsPath, ...) come to mind here. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 18:25:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:25:35 -0500 Subject: [M3devel] ARM_DARWIN? In-Reply-To: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> References: <8637A828-6FB0-470D-8F52-225BECDC09C1@darko.org> Message-ID: I am interested, though I don't have any immediate need. On Feb 19, 2008, at 5:32 AM, Darko wrote: > I'm interested in targeting Darwin on the ARM processor, to allow > software development for Apple touchscreen hardware such as the > iPhone and the iPod touch. Is anyone else interested in this? I > know there has been some work by others (see posts here by Iztok > Kobal) on targeting processors in the ARM family. > > The hardware mentioned definitely runs Darwin, or something very > much like it. Apparently the CPU is an ARM 11 on the iPhone. > > Apple is due to release an SDK shortly that will almost certainly > mean there will be an ARM target in the standard (XCode) toolchain > so it should be a matter of adapting Apple's back end as > distributed. It would have to be a cross compiler since being > hosted on the target hardware isn't very practical. > > I'd be very interested to hear from anyone with an interest in this > platform. > > Regards, > Darko. From hosking at cs.purdue.edu Thu Feb 21 18:44:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:44:00 -0500 Subject: [M3devel] Building minimal and fresh cm3... In-Reply-To: <1203610084.11244.14.camel@hias.m3w.org> References: <1203610084.11244.14.camel@hias.m3w.org> Message-ID: Yes, a number of packages got added to the minimal distro. I would have preferred to avoid m3objfile and m3back since they are (currently) only for Windows targets, but they may become more useful on other x86 platforms in future. On Feb 21, 2008, at 11:08 AM, Dragi?a Duri? wrote: > I am trying to make minimal binary rpm for latest cm3. I am creating > it's contents with: > > *** copied and edited cm3.cfg for new root. Set M3CONFIG to point > to it. > > *** copied cm3cg into new .../bin (Do I need ONLY these three files > for > bootstrap only??? cm3, cm3cg and cm3.cfg) > > *** checked out yesterday's head > > *** did ./scripts/do-cm3-std.sh buildship > > At this moment, I would like to bootstrap new compiler. I see there's > "sysutils" package now, so probably I have to modify former list of > packages, and I did it so I typed: > > *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker > m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; > cm3 -ship) > > All went well, except I had to add m3objfile (and later m3back) > because > of: > > "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/ > m3makefile", > line 24: quake runtime error: unable to open > "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading > > I supposse I also have to build m3cc so I have latest cm3cg? > > *** did ./scripts/do-cm3-std.sh buildship so all is build with latest > cm3. > > Is this all I need to have brand new hierarchy I can pack into rpm > and > distribute? > > dd > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Thu Feb 21 18:54:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 21 Feb 2008 12:54:54 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <20080221174830.c6nor8rp8gsgw8go@mail.elegosoft.com> Message-ID: I will dip my toe into this swamp only to make some high-level observations. First, until we can come up with a well-specified abstraction in the form of a clean M3 interface I for one will find it increasingly difficult to follow the motivation and developments of any scheme. In the face of that difficulty, I strongly prefer to stick to the current, non-portable, approach (ie, different path encodings for different targets maintained *separately*). This will minimize disturbance for the many of us that only work on POSIX targets and need those to stay stable. I am very nervous that my POSIX target will start to behave strangely or differently because of some interim commit to a rapidly evolving code base. Hence, I applaud Olaf's suggestion that we come up with a clean design before we start hacking, and that the implementation stay off the critical path until it has been well-tested and understood. On Feb 21, 2008, at 11:48 AM, Olaf Wagner wrote: > Quoting Jay : >> I'd like to make "progress" on what I have -- mainly slash >> independence, no colon hack on Unix. >> And then see about making much more progress. > > OK. > >> M3Path compromises a few bits of functionality, some of which >> could go in libm3, but not all. >> >> It has "path cleanup", of a sort that was strongly suggested here >> to be wrong. >> That is, "cleanup" of a/./b to a/b, a/../b to b. >> Incorrect in the face of links. >> But still general purpose if people want it. >> The code that does this work I think can stand a rewrite. It is >> currently limited to 31 slashes and after that it just silently >> ignores stuff. If you reverse the path first, do the work, >> reverse again, you can support unlimited lengths with small fixed >> memory (smaller than it currently uses to support limit lengths). >> >> It has "path conversion" between "host" and "target". >> This is specially just changing slashes around. >> It does not deal with "drive letters". > > I see. This could be abstracted, too, though. > >> It deals with "file types". >> This is an area that probably does not belong in libm3. >> "types" are, you know, .m3, .i3, reasonably simple, but also >> libfoo.a vs. foo.lib. >> There is code to pick apart paths to "in that way", which I >> find..a little unusual. > > OK. This is rather compiler specific. > >> I did already change the Win32 Pathname implementation to always/ >> usually treat forward and backward slashes as the same. That goes >> pretty far. >> >> I believe the Pathname abstraction is that a path is essentially >> an array of strings, you can add/remove from either end, add to >> one or the other or both ends, and join two. > > Yes, but it could be extended. There is also some support for > different kinds of `roots'. > >> An issue I'm avoiding..because I don't want to pollute the code >> with calls out ot Cygwin, is "correct" conversion between Win32 >> and Cygwin paths. Generally the conversion is c:\foo <=> / >> cygdrive/foo. >> >> I haven't seen how "network paths" are handled. >> >> Path handling is a surprisingly large rats nest of subtle >> behaviors and I'm not sure I really want to open it. > > I'll second that. > >> Really, there are a few Win32 behaviors that i haven't gotten into.. >> >> Even if you ignore Win32 -- what about case sensitivity? Even on >> Mac and presumably Unix (to a Mac or Windows server), you can >> encounter case insensitive file systems. The current Modula-3 >> code is not prepared for that. > > Case sensitivity of file names should be handled centrally, too. > It could be a property of a filename. But then that property needs to > be set by someone - runtime, environment, user, application... > As this is a big issue for portability of code, I'd say we should > come up with some sound concept here, but of course that can be > independent of your current work. > >> One of my favorite sob stories here, I've probably told it here, >> is that I have a low end NAS (it won't boot lately..). It runs >> Linux, of course (I said it is low end). I downloaded it source, >> extracted it, xcopied, xcopyied it again incrementally. That >> fails. Because some of the file names start with a dot and on >> Unix, that means they are hidden and cannot be unhidden.. > > `Hidden' on Unix usually only means that files are not shown with > a simple `ls'. There's nothing special in the system to treat dot- > files > different from others as far as I know. > >> So this whole "hidden" thing is not portable, just as colons in >> paths are not portable, but they work just fine if you stay on >> one system... > >> Let me get M3Path to where I want it, and repair the Unix colon >> behavior, and see about rewriting the "cleanup" code... as long >> as folks are happy with how it ends up, I'm not sure I want to >> puruse it much more. There are much bigger fish... > > OK, I can understand that you just want to finishd your current work. > >> Oh, I already have code on my system so that when we read ROOT, >> CM3_INSTALL, CM3_ROOT from the command line and/or environment, >> those paths get "fixed up" -- slashes reversed. That should help >> a lot here, without much pollution.. > > It should help, but it also needs to be tested on different platforms. > >> One thing I'm not sure about is the treatment of backward slashes >> equivalent to forward slashes on Posix. >> Maybe better just to do that fixup upon a few certain inputs. And >> have Win32 use either, but Posix only forward. >> It's "harmless" but loose. > > Yes, I'd be rather conservative there, too. > >> There this general problem of "user input" vs. "internal, >> strongly typed, analyzed, rule-following" data. >> As well as then presenting the internal data back to the user in >> the form he expected. >> >> It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo >> but when an error message is reported, in case I am going to copy/ >> paste the paths in it to file.open, it should be back with >> backward slashes. This is not simple. You could maintain two >> parallel representations as you muck with the path. Not great. >> You could "characterize" the form of the user in put (which >> slash directory), keep that around, it's just one bit, and use it >> to guide the later presentation... > > One internal, abstract representation of the data, and two or more > views on it (getPosixPath, getWindowsPath, ...) come to mind here. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 19:09:13 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 Feb 2008 19:09:13 +0100 Subject: [M3devel] Building minimal and fresh cm3... In-Reply-To: <1203610084.11244.14.camel@hias.m3w.org> References: <1203610084.11244.14.camel@hias.m3w.org> Message-ID: <20080221190913.mzepfpxvls0c4g44@mail.elegosoft.com> Why not just use scripts/make-bin-dist-min.sh? This is run nightly for all tested platforms, too. If you could add a switch to produce an rpm archive on Linux, that could be done automatically, too. Olaf Quoting Dragi?a Duri? : > I am trying to make minimal binary rpm for latest cm3. I am creating > it's contents with: > > *** copied and edited cm3.cfg for new root. Set M3CONFIG to point to it. > > *** copied cm3cg into new .../bin (Do I need ONLY these three files for > bootstrap only??? cm3, cm3cg and cm3.cfg) > > *** checked out yesterday's head > > *** did ./scripts/do-cm3-std.sh buildship > > At this moment, I would like to bootstrap new compiler. I see there's > "sysutils" package now, so probably I have to modify former list of > packages, and I did it so I typed: > > *** for i in m3-libs/sysutils m3-sys/m3middle m3-sys/m3linker > m3-sys/m3front m3-sys/m3quake m3-sys/cm3; (cd $i; cm3 -realclean; cm3; > cm3 -ship) > > All went well, except I had to add m3objfile (and later m3back) because > of: > > "/home/dragisha/src/cm3-cvshead-20080221/cm3/m3-sys/cm3/src/m3makefile", > line 24: quake runtime error: unable to open > "/home/dragisha/cm3/pkg/m3objfile/LINUXLIBC6/.M3EXPORTS" for reading > > I supposse I also have to build m3cc so I have latest cm3cg? > > *** did ./scripts/do-cm3-std.sh buildship so all is build with latest > cm3. > > Is this all I need to have brand new hierarchy I can pack into rpm and > distribute? > > dd > > -- > Dragi?a Duri? > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 21 21:16:41 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 21 Feb 2008 15:16:41 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> Message-ID: <47BD95D6.1E75.00D7.1@scires.com> I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy >>> Jay 2/21/2008 7:56 AM >>> "Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix. And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong. That is, "cleanup" of a/./b to a/b, a/../b to b. Incorrect in the face of links. But still general purpose if people want it. The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target". This is specially just changing slashes around. It does not deal with "drive letters". It deals with "file types". This is an area that probably does not belong in libm3. "types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib. There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix. Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward. It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data. As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo but when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100 > From: wagner at elegosoft.com > To: jayk123 at hotmail.com > CC: mika at async.caltech.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > I have some ideas here that I am pretty certain WILL be acceptable. > > But I'd like to know if the current behavior really isn't. > > > > The ideas are: > > 1) > > (* A well designed approach might look like this, however how do > > we determine the target behavior? > > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END; > > SepKind_t = { Unix, Win, Winx }; > > > > CONST > > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, }; > > *) > > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix". > > > > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial. > > > > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more. > > Like into m3quake (QPath?) or m3middle (M3Path?). > > > > However I worry about the effect on source control history. > > Advise? > > > > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3. > > I agree that we should have one central abstraction of the pathanme > type. What about pushing it further into libm3/.../Pathname? This would > need carefully checking of compatibility of course. Also I wouldn't > like to see variables exposed in such a module; we should use > functions or procedures for everything there. > > Do you see any problem in providing such a globally unique and > compatible abstraction? > > Could you provide a complete (documented) Pathname module that could be > discussed on this list and tested by everybody interested? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Shed those extra pounds with MSN and The Biggest Loser! Learn more. ( http://biggestloser.msn.com/ ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 06:26:43 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 05:26:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47BD95D6.1E75.00D7.1@scires.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <47BD95D6.1E75.00D7.1@scires.com> Message-ID: I made one change to the Win32 Pathname implementation and that will be it unless there is more thought and consensus. That change is to treat forward and backward slashes "the same", essentially as the underlying layer (kernel32.dll) already does. Is this not ok? You do all realize that Win32 /largely/ accepts forward slashes just fine, right? There are some exceptions.It is the functions in kernel32.dll that accept them. Not necessarily shlwapi.dll and definitely not the file.open dialogs. There is way in which forward slashes don't work. I can explain later. M3Path currently has "strange" behavior on Posix for colon and backward slash. I have the colon and I think backslash parts fixed on my machine. Essentially I have: CONST Slash = '/'; VAR (* formerly CONST *) Backslash := '\000'; (* initial value for Posix *) Colon := '\000'; (* initial value for Posix *)IsDirSep(ch) return (ch = Slash OR ch = Backslash) IsSep(ch) return (ch = Slash OR ch = Backslash OR ch = Colon) I do actually worry about nulls in strings sometimes but nobody else seems to. Allowing nulls is an advantage of approaches that keep a length separate. I believe the previous code was already sleazy this way. BEGIN (* Module initialization *) LocalSlash := Text.GetChar ( Pathname.Join ("a", "b"), 1); IF LocalSlash = '\\' THEN BackSlash := '\\'; Colon := ':'; ELSE OS := Env.Get ("OS"); IF OS # NIL AND Text.Equal (OS, "Windows_NT") THEN same thing END END; The point being to accept colons and backslashes on NT386 and Cygwin. One thing I don't quite get and people here probably don't realize is that the compiler tries to traffice in both host and target paths. It's not just about portabily using the host system, as people are so happy with the existing libm3 for. Now, I'm not sure what the point is, and I am skeptical it even works. I think the point might be for when bootstrapping, maybe to use the .M3SHIP files on the target. This need to deal with more than just the host system's paths MIGHT be something for libm3. Some way to "sniff" a path for its type, and then deal with it using the interfaces. This is probably easily done just be exposing PathPosix and PathWin32, which implement themselves and Path. The interface could just be Path to start, plus an explicit "create" function to get started, and maybe a "get" function to get the string as a regular string. A function "FixUp" or specifically "CleanupSlashes" that changes runs of slashes to single slashes, and "RemoveSingleDots" and "RemoveDoubleDots" might be ok to provide but you'd have to call them manually. Gotta go, - Jay Date: Thu, 21 Feb 2008 15:16:41 -0500From: rcoleburn at scires.comTo: wagner at elegosoft.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy>>> Jay 2/21/2008 7:56 AM >>>"Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix.And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong.That is, "cleanup" of a/./b to a/b, a/../b to b.Incorrect in the face of links.But still general purpose if people want it.The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target".This is specially just changing slashes around.It does not deal with "drive letters". It deals with "file types".This is an area that probably does not belong in libm3."types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib.There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix.Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward.It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data.As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foobut when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 08:37:37 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 07:37:37 +0000 Subject: [M3devel] some vagaries of Win32 path semantics (and some Mac) Message-ID: some vagaries of Win32 path semantics (and some Mac) You can learn about this stuff by looking at the NT namespace with winobj.And/or watching calls to NtCreateFile in a debugger.And/or with filemon.And/or reading the documentation for driver writers.And/or various documentation about the NT kernel interface.And/or experimenting with cmd (assuming cmd isn't doing the wierd stuff). This is about kernel32.dll for now. When using 8 bit characters, the length limit is 260 characters.Whether or not that includes the terminal zero is not clear. When using 16 bit characters, the "default" limit is also 260 characters. MS-DOS limit is 64 or maybe 128 characters, so this is progress. (!) Unix limit I think is usually around 1024. That's still pretty lame imho, just a little less lame. The actual Windows limit is 32K which seems pretty ok to me, though 16bit limits are surprising. The limit on INDIVIDUAL PATH ELEMENTS, as dictated by FindFirstFile/FindNextFileis also 260 characters. But again, for individual path elements.I haven't tried exceeding that. The creation paths don't clearly havethis limit. It is worth experimenting with. Ignoring Windows 9x, everything is built on top of the NT kernel.Most interesting here is NtCreateFile. At the kernel level, "relative opens" are allowed.All the various "name" or "path" based functions don't just take a string,they take an OBJECT_ATTRIBUTES.This is mainly flags, an optional parent handle, and a unicode string.The length of the unicode string is stored in an unsigned shortrepresenting a number of bytes. So the limit is around 32,767.One of the flags controls case sensitivity, for example, at least somewhat.I don't know what happens if you try to be case sensitive on FAT, for example. NTFS allows volumes to be mounted in empty directories.I assume such a volume could be FAT, so even if c:\ is NTFS and capableof case sensitivity, c:\foo might not be. If you are doing a non-relative open at the NT level, there is no working directoryor relative paths or such. There is basically just full paths.They don't look quite exactly like anything else.They look like \??\c:\windows\system32\kernel32.dll or \??\unc\machine\share\foo\bar.txt \?? before around NT4 was named \DosDevices.I suspect \?? was an optimization -- making the common case a shorter string.Seems lame but oh well.You can see in driver stuff about setting up symbolic links related to \DosDevices. Yes, NT has symbolic links, in the kernel namespace. At the kernel32.dll level, the documentation clearly exposes something very related.To open paths longer than 260 characters, they say to use the prefixes: \\? or \\?\unc Last I checked, the documentation was a little unclear.What they mean is, to form paths like: \\?\c:\windows\system32\kernel32.dll \\?\unc\machine\share\foo\bar.txt They don't say so, but quick attempts otherwise clearly show, thatthe paths must be full paths. No relative to any "current working directory". An implementation trick should be evident.Just change the second character from \ to ? and you get an NT path. The documentation says \\? "turns off path parsing". Usually all file paths undergo some amount of canonicalization.Forward slashes are changed to backward slashes.Runs of backward slashes are changed to a single slash.Spaces might be removed in some places?Trailing dots also?That is what \\? "turns off". You can see this if you make some CreateFile calls and watch the resulting NtCreateFile.I should put together a demo. Using some hack to intercept the NtCreateFile call. Nearly everything is demoable from the command line.Try this: C:\> mkdir "foo" C:\> mkdir "foo " A subdirectory or file foo already exists. Huh? C:\>mkdir foo. A subdirectory or file foo. already exists. Huh? C:\>mkdir " foo" ok. C:\>mkdir "\\?\c:\foo"C:\>mkdir "\\?\c:\foo " => works rmdir "\\?\c:\foo " C:\>mkdir "\\?\c:\foo." C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\ 02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>rmdir foo.The system cannot find the file specified. Huh? C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\ 02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>mkdir bar. C:\>rmdir bar. C:\>mkdir bar. C:\>rmdir bar huh? mkdir "foo \bar" dir foo expands to "foo " because tab found it but then enterand File Not Found Huh? C:\>mkdir "\\?\c:\foo/" The filename, directory name, or volume label syntax is incorrect. => forward slash not liked C:\>mkdir "c:\foo/" => no error C:\>mkdir "\\?\c:\foo\..\bar" The filename, directory name, or volume label syntax is incorrect. => .. apparently not liked I tried . and that did work. C:\>mkdir c:\foo\..\bar => ok So now I ask -- what is the portable interface and implementation? Most code uses CreateFile and doesn't use \\?. So most code is limited to MAX_PATH and has problems with spaces and dots in some places. These features are all laudable -- allow paths with more than 260 characters and with spaces and dots in more places, if the programmer or user really wants, but this \\? vs. \\? behavior is strange. Trailing spaces in paths tend to be "invisible" in any user interface. (I wonder about tabs too, vertical space, beep, etc.) Note that not everything goes through Win32 usermode CreateFile/kernel32.dll. It is not the one and only path to the file system, but it is overwhelmingly common. Imagine going over the network from a non-Windows client (e.g. Samba) And maybe Services for Unix. shlwapi.dll and even shell32.dll also have a bunch of path/file unitility functions. I've hardly ever used them. I think I tried forward slashes with shlwapi.dll once and no go. In an ntsd/cdb/windbg, try a breakpoint like: bp ntdll!NtCreateFile "!obja poi(@esp+c);g" That will trace the paths to NtCreateFile. It is a low tech filemon.esp is the stack pointer and the object attributes is the third parameter (4*3=c),and !obja prints object attributes. I got bored writing this and maybe didn't finish covering everything, sorry.The thing to do is experiment and see what all changes between CreateFile and NtCreateFile.e.g. paths relative to the current working directory. Oh, also, there is a relative working directory per volume on Windows.There are special environment variables used to store them.Something like the variable =c: has c:'s working directory. C:\>echo %=c:% C:\ C:\>cd foo C:\foo>echo %=c:% C:\foo I only have one volume, so let's make another: C:\foo>subst d: c:\ d: cd bar D:\bar>echo %=d:% D:\bar c: brings me back to c:\foo cd d:\windows changes the working directory of D:, but doesn't bring me there d: now I am on the d: drive You can use /d to cd to change drive and directory at the same time. Cygwin also uses NtCreateFile sometimes. I haven't yet looked at why. NTFS has hardlinks for files, not directories (avoid cycles and I guess adequate for strict Posix?). NTFS on Vista has symlinks I guess for files and directories, not sure. Windows 2000 added a CreateHardLink function. XP has "fsutil hardlink create newlink existingfile" Vista has that and "mklink". Also, on my Mac I can create filenames with forward slashes in them.I have some old files from www.apple.com named like "C/C++ compiler reference".At the command line I think the forward slashes show as colons.Historically on the Mac the colon is path separator, but the "syntax"is different than Posix and Windows. Pathname.i3 documents it. If you read the Mac OS X overviews, you can see Mac OS X is a tremendous mish-mashof similar redundant interfaces and implementations.There are many sets of functions for doing the same thing.There are older functions for example that take 8 bit characters, with limits of255, though usually I believe you do directory relative opens. There are newer APIs that use Unicode and are more opaque. You can have two volumes with the same nameso: :hard disk:foo:bar (at least on Mac OS Classic, not sure about X)can actually name any number of files on Mac, depending on how many disks are named "hard disk". I think what you have to do is enumerate volumes, get their "reference numbers" and do relativeopens from there. so much for string equality meaning two paths reference the same file.Now, granted, if you do two open calls with the same path, I assume it always gets the same one.However, what if in the meantime, more volumes come online?Maybe earlier mounted is earlier opened and consistent? Big mess. (GS/OS on the long dead Apple IIGS also has this forward slash or colon behavior,and I think instead of one current working directory, you could assign a bunch ofthem to numbers. I think file names couldn't start with numbers, or maybe that was ambiguous.) - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 10:00:04 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 09:00:04 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47BD95D6.1E75.00D7.1@scires.com> References: Your message of "Mon, 18 Feb 2008 19:37:10 GMT." <200802182204.m1IM47eI037784@camembert.async.caltech.edu> <20080221114225.zqq484wq68swcc0o@mail.elegosoft.com> <47BD95D6.1E75.00D7.1@scires.com> Message-ID: As long as \ never occurs, no change. Even if it does..think about it. Before \ was treated as a "regular" character, allowed in paths. It is very unlikely, but not impossible, that \ ever occured, and then it is also unlikely, but not impossible, for the opens with \ to succeed at the next level down. It is more likely to have failed. And then it is very unlikely, but again not impossible, to imagine that code could be depending on this failure. Every single line changed is a change that must be thought through. The implementation is the interface. It is impossible to separate out something smaller and claim it is all other code depends on. For any given change, I can probably come up with code that it broke. If you use more memory, there could be code on the verge of running out of memory that you pushed over the edge. If you expand some limit, there could be code relying on things having smaller limits. If you make something faster, you can expose a race condition, that was already there but tending not to occur. If you make something slower, well, people will just complain. If all I do is add some new functions, well, like memory, I was almost out of disk space or more realistically virtual address space, and now I am. This is a real example. I have seen some code break just because other code grew in size. The code was arguably buggy, but that is besides the point. That doesn't mean that nothing can be changed. You just have to apply reason. So, for the case of backward slashes in Posix paths, is treating them like forward slashes dangerous?This is only in M3Path.m3, that the compiler uses. It is not in the more widely used Pathname module in libm3. I'm going to undo th change and leave it only for "NT386GNU", and I have to double double check that it helps there..well, I know it helps upon input. Imagine you have a text file with some paths and you move it across machines.. Do you: invent a new abstract "path" to store in the file, and write translation on either side ? adopt an existing form and translate on foreign systems ? adopt what looks very nearly like very system's format and be a little careful ? In the form you chose, can you represent anything that is possibly valid? Or do get a bit lazy and disallow some paths, like forward slashes (legal on Mac OS remember) ? A start to an abstract representation is an array of strings, and the strings can have any character, and they have a length stored (don't depend on either space or null termination). a "text" file format becomes less convenient now, because there is no delimiter, you have to store the length. You can still do that as text, it's just less convenient to edit. If you can get away with only storing full paths, that is probably an adequate represenation. If you want some indirection, it is probably useful to decide some "roots", some common prefixes, and factor that out somehow. But this depends on the application. And/Or maybe on the recieving end there is a "search algorithm". I'm just saying, this area is complicated, I know it is complicated. Forward slashes usually do have the same meaning on Win32 as backward slashes AND my goal here to make the system easier to use for anyone, such as myself, using NT386 and NT386GNU. I shouldn't have to set install root and the source root differently between them. Maybe this is just me and I'm lazy and I should suck it up, but if I only have one drive, the ability to use just /cm3 and /dev2/cm3.2 is so close to already being there..and furthermore...if someone is using NT386GNU, but any "normal" Windows editor (ie: not Cygwin vi/emacs), they will want errors printed out with backward slashes so they can copy/paste them into their editor. I guess the "presentation format" should be user configurable. Where "presentation format" could be limited what slash to use. Leaving the user to possibly prefix with c: or /cygdrive/c, which is at least less tedious than changing all the slashes.. That's kind of the thing -- user input and output paths should be more flexible and/or configurable than internal forms. However internal forms should not be warped much or at all to handle this, only input/output functions that mediate between the two. One form caters to various users with various tastes. One form caters to code that is simpler to have just one form and benefits not at all from other forms. The "temptation" though is to make them the same. Anyway, I have this "FixupPath" function that should basically make things this way. I maybe can remove the allowance for the different slashes anywhere else. The output issue is bothering me less right now than the input issue, and even the input issue I had mostly sucked up anyway. I think I was hitting some other problem not related to my own taste/laziness that made me revisit this. As it was, I had already "rewritten" M3Path.m3 twice and then abandoned it, figuring that the original authors had already figured this stuff out and it must already be right..but then I looked at it more and no longer thing that. I don't believe the "naming convention" declared in config files ever did much. All that determined things was the runtime probed slash that Pathname.i3 used. So, making NT386GNU use forward slashes but otherwise Windows naming conventions didn't work. I don't think, correct me if I'm wrong, I don't think libfoo.a vs. foo.lib should be tied with / vs. \. However, I also don't mind switching to libfoo.a for NT386GNU (a target I'm not likely to use once it work..). Maybe I should move on to that. Well, can't leave things as they are anyway... - Jay Date: Thu, 21 Feb 2008 15:16:41 -0500From: rcoleburn at scires.comTo: wagner at elegosoft.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 I'm not convinced that it is *harmless* to change the code to treat "/" and "\" the same. This seems like a potential "can of worms" that may create side-effects not well understood at this time. My understanding of the original design of things is that the desire was to provide standardized interfaces that allowed the programmer to construct and manipulate paths independent of the OS's path separator. If you use the standardized interfaces you don't have a problem; however, if you try to provide complete paths as literals, then yes, you are introducing an OS-specific behavior into your code--which is not a good thing if you want your code to be portable between OS. I have code that manipulates paths and runs properly on both Windows and Unix without any source code modifications BECAUSE I use the standard interfaces to build and manipulate paths. Please let me know why you think it is important to change the behavior of the existing code. BTW, when you change such behavior, you are changing the contract set up by the interface and any documentation (comments) in that interface. Whenever such a contract change is made, ALL modules everywhere that import this interface must be examined to see if the changes in the contract will adversely affect or break the desired behavior of the module. I think we need to be very careful here! Regards, Randy>>> Jay 2/21/2008 7:56 AM >>>"Maybe"? I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix.And then see about making much more progress. M3Path compromises a few bits of functionality, some of which could go in libm3, but not all. It has "path cleanup", of a sort that was strongly suggested here to be wrong.That is, "cleanup" of a/./b to a/b, a/../b to b.Incorrect in the face of links.But still general purpose if people want it.The code that does this work I think can stand a rewrite. It is currently limited to 31 slashes and after that it just silently ignores stuff. If you reverse the path first, do the work, reverse again, you can support unlimited lengths with small fixed memory (smaller than it currently uses to support limit lengths). It has "path conversion" between "host" and "target".This is specially just changing slashes around.It does not deal with "drive letters". It deals with "file types".This is an area that probably does not belong in libm3."types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib.There is code to pick apart paths to "in that way", which I find..a little unusual. I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far. I believe the Pathname abstraction is that a path is essentially an array of strings, you can add/remove from either end, add to one or the other or both ends, and join two. An issue I'm avoiding..because I don't want to pollute the code with calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo. I haven't seen how "network paths" are handled. Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it. Really, there are a few Win32 behaviors that i haven't gotten into.. Even if you ignore Win32 -- what about case sensitivity? Even on Mac and presumably Unix (to a Mac or Windows server), you can encounter case insensitive file systems. The current Modula-3 code is not prepared for that. One of my favorite sob stories here, I've probably told it here, is that I have a low end NAS (it won't boot lately..). It runs Linux, of course (I said it is low end). I downloaded it source, extracted it, xcopied, xcopyied it again incrementally. That fails. Because some of the file names start with a dot and on Unix, that means they are hidden and cannot be unhidden.. So this whole "hidden" thing is not portable, just as colons in paths are not portable, but they work just fine if you stay on one system... Let me get M3Path to where I want it, and repair the Unix colon behavior, and see about rewriting the "cleanup" code... as long as folks are happy with how it ends up, I'm not sure I want to puruse it much more. There are much bigger fish... Oh, I already have code on my system so that when we read ROOT, CM3_INSTALL, CM3_ROOT from the command line and/or environment, those paths get "fixed up" -- slashes reversed. That should help a lot here, without much pollution.. One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix.Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward.It's "harmless" but loose. There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data.As well as then presenting the internal data back to the user in the form he expected. It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foobut when an error message is reported, in case I am going to copy/paste the paths in it to file.open, it should be back with backward slashes. This is not simple. You could maintain two parallel representations as you muck with the path. Not great. You could "characterize" the form of the user in put (which slash directory), keep that around, it's just one bit, and use it to guide the later presentation... - Jay > Date: Thu, 21 Feb 2008 11:42:25 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: mika at async.caltech.edu; m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > I have some ideas here that I am pretty certain WILL be acceptable.> > But I'd like to know if the current behavior really isn't.> >> > The ideas are:> > 1)> > (* A well designed approach might look like this, however how do > > we determine the target behavior?> > Seps_t = RECORD (* Whenever a character must be "written", > > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. > > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep > > : CHAR; DirSepText : TEXT; END;> > SepKind_t = { Unix, Win, Winx };> >> > CONST> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', > > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', > > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };> > *)> > and then I think m3middle would have to specify the behavior of each > > target -- of course most are "Unix".> >> > 2) less work for now, very much like the current behavior, except > > Colon changes from CONST to VAR and is ':' if the environment > > variable OS == "Windows_NT", else '\000'. The support for > > backslashes could key off this too, though I believe it is FAR less > > controversial.> >> > Also, I want to move m3path.m3 into a lower layer so it useable a > > little more.> > Like into m3quake (QPath?) or m3middle (M3Path?).> >> > However I worry about the effect on source control history.> > Advise?> >> > For now I've got one path function in one m3quake file, another path > > function in another m3quake file, and everything else remaining in > > cm3/src/M3Path.m3.> > I agree that we should have one central abstraction of the pathanme> type. What about pushing it further into libm3/.../Pathname? This would> need carefully checking of compatibility of course. Also I wouldn't> like to see variables exposed in such a module; we should use> functions or procedures for everything there.> > Do you see any problem in providing such a globally unique and> compatible abstraction?> > Could you provide a complete (documented) Pathname module that could be> discussed on this list and tested by everybody interested?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 11:09:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 10:09:41 +0000 Subject: [M3devel] some vagaries of Win32 path semantics (and some Mac) Message-ID: I remembered more complications. Remember that many of these are exposed to Unix via Windows file servers. And of course Mac -- notice that PPC_DARWIN is case sensitive about names, even though that is commonly "wrong". But again, it varies per file system, not "POSIX" vs. "WIN32" ("POSIX" as in Modula-3 source directory/OS_TYPE. I don't know about the standard.) When you are case insensitive, just what are the rules? M3Path handles only a-z. And it doesn't handle Unicode anyway I think, not sure. On NTFS.. C:\>more < $UpcaseAccess is denied. C:\>more < $UpcasexThe system cannot find the file specified. C:\> http://www.ntfs.com/ntfs-system-files.htm There's also a technote on www.apple.com talking about precomposed or non-precomposed and what is canonical. This has something to do with accent characters. And short names are funky. You can turn off the generation of them. I think I sent there here already, but watch this: First, they aren't necessarily shorter than long names. In this case the short name is twice the length of the long name. Short names are always limited to 8.3 though, one dot, and certain characters (ie: not Unicode, I think). C:\>mkdir 1.1.1 C:\>dir /x 1*02/22/2008 02:03 AM 112E5D~1.1 1.1.1 Second, wildcard matching (FindFirstFile/FindNextFile) always includes them: C:\>mkdir foo.bar C:\>mkdir foo.barf C:\>dir *.bar 02/22/2008 02:04 AM foo.bar02/22/2008 02:04 AM foo.barf Huh? C:\>dir /x *bar02/22/2008 02:04 AM foo.bar02/22/2008 02:04 AM FOO~1.BAR foo.barf Oh.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: some vagaries of Win32 path semantics (and some Mac)Date: Fri, 22 Feb 2008 07:37:37 +0000 some vagaries of Win32 path semantics (and some Mac) You can learn about this stuff by looking at the NT namespace with winobj.And/or watching calls to NtCreateFile in a debugger.And/or with filemon.And/or reading the documentation for driver writers.And/or various documentation about the NT kernel interface.And/or experimenting with cmd (assuming cmd isn't doing the wierd stuff).This is about kernel32.dll for now.When using 8 bit characters, the length limit is 260 characters.Whether or not that includes the terminal zero is not clear.When using 16 bit characters, the "default" limit is also 260 characters. MS-DOS limit is 64 or maybe 128 characters, so this is progress. (!) Unix limit I think is usually around 1024. That's still pretty lame imho, just a little less lame. The actual Windows limit is 32K which seems pretty ok to me, though 16bit limits are surprising.The limit on INDIVIDUAL PATH ELEMENTS, as dictated by FindFirstFile/FindNextFileis also 260 characters. But again, for individual path elements.I haven't tried exceeding that. The creation paths don't clearly havethis limit. It is worth experimenting with.Ignoring Windows 9x, everything is built on top of the NT kernel.Most interesting here is NtCreateFile.At the kernel level, "relative opens" are allowed.All the various "name" or "path" based functions don't just take a string,they take an OBJECT_ATTRIBUTES.This is mainly flags, an optional parent handle, and a unicode string.The length of the unicode string is stored in an unsigned shortrepresenting a number of bytes. So the limit is around 32,767.One of the flags controls case sensitivity, for example, at least somewhat.I don't know what happens if you try to be case sensitive on FAT, for example.NTFS allows volumes to be mounted in empty directories.I assume such a volume could be FAT, so even if c:\ is NTFS and capableof case sensitivity, c:\foo might not be.If you are doing a non-relative open at the NT level, there is no working directoryor relative paths or such. There is basically just full paths.They don't look quite exactly like anything else.They look like \??\c:\windows\system32\kernel32.dll or \??\unc\machine\share\foo\bar.txt \?? before around NT4 was named \DosDevices.I suspect \?? was an optimization -- making the common case a shorter string.Seems lame but oh well.You can see in driver stuff about setting up symbolic links related to \DosDevices.Yes, NT has symbolic links, in the kernel namespace.At the kernel32.dll level, the documentation clearly exposes something very related.To open paths longer than 260 characters, they say to use the prefixes: \\? or \\?\uncLast I checked, the documentation was a little unclear.What they mean is, to form paths like: \\?\c:\windows\system32\kernel32.dll \\?\unc\machine\share\foo\bar.txt They don't say so, but quick attempts otherwise clearly show, thatthe paths must be full paths. No relative to any "current working directory".An implementation trick should be evident.Just change the second character from \ to ? and you get an NT path.The documentation says \\? "turns off path parsing".Usually all file paths undergo some amount of canonicalization.Forward slashes are changed to backward slashes.Runs of backward slashes are changed to a single slash.Spaces might be removed in some places?Trailing dots also?That is what \\? "turns off".You can see this if you make some CreateFile calls and watch the resulting NtCreateFile.I should put together a demo. Using some hack to intercept the NtCreateFile call.Nearly everything is demoable from the command line.Try this: C:\> mkdir "foo" C:\> mkdir "foo " A subdirectory or file foo already exists. Huh? C:\>mkdir foo. A subdirectory or file foo. already exists. Huh? C:\>mkdir " foo"ok.C:\>mkdir "\\?\c:\foo"C:\>mkdir "\\?\c:\foo " => works rmdir "\\?\c:\foo "C:\>mkdir "\\?\c:\foo."C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes freeC:\>rmdir foo.The system cannot find the file specified.Huh?C:\>dir fo* Volume in drive C has no label. Volume Serial Number is A803-BC73 Directory of C:\02/21/2008 11:07 PM foo02/21/2008 11:07 PM foo. 0 File(s) 0 bytes 2 Dir(s) 26,666,397,696 bytes free C:\>mkdir bar. C:\>rmdir bar. C:\>mkdir bar. C:\>rmdir bar huh? mkdir "foo \bar" dir foo expands to "foo " because tab found it but then enterand File Not Found Huh? C:\>mkdir "\\?\c:\foo/" The filename, directory name, or volume label syntax is incorrect. => forward slash not liked C:\>mkdir "c:\foo/" => no error C:\>mkdir "\\?\c:\foo\..\bar" The filename, directory name, or volume label syntax is incorrect. => .. apparently not liked I tried . and that did work. C:\>mkdir c:\foo\..\bar => ok So now I ask -- what is the portable interface and implementation? Most code uses CreateFile and doesn't use \\?. So most code is limited to MAX_PATH and has problems with spaces and dots in some places. These features are all laudable -- allow paths with more than 260 characters and with spaces and dots in more places, if the programmer or user really wants, but this \\? vs. \\? behavior is strange. Trailing spaces in paths tend to be "invisible" in any user interface.(I wonder about tabs too, vertical space, beep, etc.) Note that not everything goes through Win32 usermode CreateFile/kernel32.dll. It is not the one and only path to the file system, but it is overwhelmingly common. Imagine going over the network from a non-Windows client (e.g. Samba) And maybe Services for Unix. shlwapi.dll and even shell32.dll also have a bunch of path/file unitility functions. I've hardly ever used them. I think I tried forward slashes with shlwapi.dll once and no go.In an ntsd/cdb/windbg, try a breakpoint like: bp ntdll!NtCreateFile "!obja poi(@esp+c);g" That will trace the paths to NtCreateFile. It is a low tech filemon.esp is the stack pointer and the object attributes is the third parameter (4*3=c),and !obja prints object attributes.I got bored writing this and maybe didn't finish covering everything, sorry.The thing to do is experiment and see what all changes between CreateFile and NtCreateFile.e.g. paths relative to the current working directory.Oh, also, there is a relative working directory per volume on Windows.There are special environment variables used to store them.Something like the variable =c: has c:'s working directory. C:\>echo %=c:% C:\ C:\>cd foo C:\foo>echo %=c:% C:\foo I only have one volume, so let's make another: C:\foo>subst d: c:\ d: cd bar D:\bar>echo %=d:% D:\bar c: brings me back to c:\foo cd d:\windows changes the working directory of D:, but doesn't bring me there d: now I am on the d: drive You can use /d to cd to change drive and directory at the same time.Cygwin also uses NtCreateFile sometimes. I haven't yet looked at why. NTFS has hardlinks for files, not directories (avoid cycles and I guess adequate for strict Posix?). NTFS on Vista has symlinks I guess for files and directories, not sure. Windows 2000 added a CreateHardLink function. XP has "fsutil hardlink create newlink existingfile" Vista has that and "mklink". Also, on my Mac I can create filenames with forward slashes in them.I have some old files from www.apple.com named like "C/C++ compiler reference".At the command line I think the forward slashes show as colons.Historically on the Mac the colon is path separator, but the "syntax"is different than Posix and Windows. Pathname.i3 documents it.If you read the Mac OS X overviews, you can see Mac OS X is a tremendous mish-mashof similar redundant interfaces and implementations.There are many sets of functions for doing the same thing.There are older functions for example that take 8 bit characters, with limits of255, though usually I believe you do directory relative opens.There are newer APIs that use Unicode and are more opaque.You can have two volumes with the same nameso: :hard disk:foo:bar (at least on Mac OS Classic, not sure about X)can actually name any number of files on Mac, depending on how many disks are named "hard disk".I think what you have to do is enumerate volumes, get their "reference numbers" and do relativeopens from there.so much for string equality meaning two paths reference the same file.Now, granted, if you do two open calls with the same path, I assume it always gets the same one.However, what if in the meantime, more volumes come online?Maybe earlier mounted is earlier opened and consistent? Big mess.(GS/OS on the long dead Apple IIGS also has this forward slash or colon behavior,and I think instead of one current working directory, you could assign a bunch ofthem to numbers. I think file names couldn't start with numbers, or maybe that was ambiguous.) - Jay Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 22 11:41:54 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 22 Feb 2008 10:41:54 +0000 Subject: [M3devel] some Cygwin path vagaries In-Reply-To: <20080222111045.2qhhuhoqo0cgo4sk@mail.elegosoft.com> References: <20080222104722.lh7jgctc68kk4wso@mail.elegosoft.com> <20080222111045.2qhhuhoqo0cgo4sk@mail.elegosoft.com> Message-ID: Well this surprised me. Cygwin fopen accepts all of /cygdrive/c/1.txt \cygdrive\c\1.txt c:\1.txt c:/1.txt They all mean the same (well, actually, that I just assume, I'm able to fopen each) c:1.txt didn't work (it would work in Win32) I thought I'd seen Cygwin not accepting Win32 paths. Geez, maybe this makes things easier.. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 22 16:24:08 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:24:08 -0600 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] Message-ID: <47BEE918.1060908@wichita.edu> This didn't appear to come through to the list the first time: -------- Original Message -------- Subject: Re: [M3devel] <*LAZYALIGN*> Date: Mon, 18 Feb 2008 20:11:17 -0600 From: Rodney M. Bates To: Randy Coleburn CC: m3devel at elegosoft.com References: <47AF72B5.2080308 at wichita.edu> <47B1168F.8020302 at wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236 at darko.org> <47B4C70D.4010408 at wichita.edu> <7323567C-7632-4040-B858-47B8124759DC at cs.purdue.edu> <47B50EDF.8060807 at wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843 at cs.purdue.edu> <47B5FB13.7070407 at wichita.edu> <20080215223205.t9a01icx4okgco0o at mail.elegosoft.com> <47B60CE0.8050506 at wichita.edu> <47B9644F.1E75.00D7.1 at scires.com> Just to clarify: I don't believe anything existing has to break. The worst scenario I can see is that you would have to either simultaneously upgrade the compiler, libm3, and libm3core (or else none of these) before recompiling & linking any code that reads or writes pickles. If libm3 and libm3core are dynamically linked in at runtime, you would have to recompile with an upgraded compiler at the same time as installing the upgraded dynamic libraries. Existing pickle files would not change. Also, mixtures of programs thus recompiled & linked and programs not recompiled/linked could exchange pickle files. Anything that (un)pickles records or objects that are LAZYALIGN would need the upgrade to work, but such programs are already broken. Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add support > for something that is rarely used. > Regards, > Randy > -- ------------------------------------------------------------- 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 -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 16:35:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:35:15 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> Message-ID: <47BEEBB3.6000800@wichita.edu> Darko wrote: > There wouldn't be any explicit expression. in the source, but there > would be a flag in Target.i3 for turning it off and on for different > platforms. > > Although the details may be a bit off, the principal is this: > > before byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 32 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) ^If the compiler's alignment rules are not lazy, then this violates a language rule and should not compile. From 2.2.5, Packed types: "...variables of type T that occur in records, objects, or arrays will occupy exactly n bits and be packed adjacent to the preceding field or element." To get the padding between a and b, you would have to either put it in with an explicit pad field, or remove the BITS 32 from the type of b. > c: BITS 16 FOR 0..65000; (* takes 32 bits *) > END; > > after byte alignment change: > > RECORD > a: BITS 8 FOR 0..255; (* takes 8 bits *) > b: BITS 32 FOR INTEGER; (* takes 32 bits *) > c: BITS 16 FOR 0..65000; (* takes 16 bits *) > END; > > > On 19/02/2008, at 3:40 PM, Tony Hosking wrote: > >> Thanks for the explanation! How does one express the alignment you >> support? >> >> It does sound like <*LAZYALIGN*> can go away. >> >> On Feb 18, 2008, at 8:44 PM, Darko wrote: >> >>> Actually rather than compilain rather grumpily, maybe I can just >>> make the >>> changes required to RTTipe and do the work to reomve the pragma. I can >>> work with Randy to ensure it doesn't break pickles, there is no >>> reason why >>> it should. >>> >>> On tha subject Randy, I assume pickles encode the number of BITS FOR >>> for a field? If not it should. >>> >>> >>>> We seem to be going through these same point several times. I'm not >>>> sure >>>> what the difficulty is, I'm just repeating myself. >>>> >>>> Keep in mind this applies *only* to packed structures, ie BIT FOR >>>> or bit >>>> fields. >>>> >>>> The change I put in libralised the *M3* alignment rules so that >>>> BITS FOR >>>> fields in structures would align on byte boundries if possible >>>> instead of >>>> restricting them to word alignment generally. GCC happily generates >>>> code >>>> for this. There may be restrictions in GCC's C as to how you can >>>> arrange >>>> bit fields but I don't see what they have to do with M3. >>>> >>>> This is absolutely essentail for using the native APIs on Mac OS X >>>> and its >>>> removal would make M3 pointless for use on the Mac, at least more me. >>>> >>>> This should be the default behviour. If you are using BITS FOR it's >>>> becuase you want to arrange the fields in a record in particular >>>> way. Why >>>> then arbitrarliy pad out the fields? If performance is an issue, >>>> the user >>>> should be using appropriate field bit sizes. The implementation >>>> rule for >>>> BITS FOR in M3 is implementation dependent, there are no language >>>> issues. >>>> >>>> The LAZYALIGN pragma (that is, the prgama itself) is something Olaf >>>> created and had nothing to do with me. I diagreed with it and never >>>> used >>>> it in the version of the compiler I ran. I support its removal. >>>> >>>> >>>> >>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>> >>>>>> The alignment behaviour is absolutely crucial to programming >>>>>> natively in Mac OS X and should be kept. I have a great need for it. >>>>>> >>>>>> The PRGAMA is of no use and can be removed. >>>>>> >>>>>> Does anyone have any objections to making this alignment behaviour >>>>>> standard? >>>>> >>>>> >>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go with >>>>> the standard gcc-backend alignment? Perhaps I don't understand what >>>>> it is you are doing or trying to do. Again, please remind me what it >>>>> is that LAZYALIGN does and why it is needed. >>>>> >>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>> >>>>>>> Can someone remind me again why we need LAZYALIGN? I concur with >>>>>>> Randy that if it is rarely used and moreso breaks things I would >>>>>>> argue to abandon it. >>>>>>> >>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>> >>>>>>>> I use pickles extensively and they are used also by network >>>>>>>> objects. >>>>>>>> I've never used LAZYALIGN. >>>>>>>> My vote is that we don't break something (pickles/netobj) to add >>>>>>>> support for something that is rarely used. >>>>>>>> Regards, >>>>>>>> Randy >>>>>>>> >>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>> >>>>>>>> PM >>> >>>>>>>> I'll put it in comments in the code. I am sure I can fix it to >>>>>>>> handle LAZYALIGN too, just not sure whether I can do it without >>>>>>>> requiring existing pickle files to be regenerated and/or existing >>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>> >>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>> pickles >>>>>>>> or compiled code were invalidated by a change? >>>>>>>> >>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>> variables of that type. >>>>>>>> >>>>>>>> Olaf Wagner wrote: >>>>>>>> >>>>>>>>> Perhaps we should check-in this description somewhere near the >>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>> >>>>>>>>> Olaf >>>>>>>>> >>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>> >>>>>>>> LAZYALIGN. >>>>>>>> >>>>>>>>> Or at least put a big sticker on that it will break pickles. >>>>>>>>> >>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>> >>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. Using >>>>>>>> >>>>>>>> BITSIZE, >>>>>>>> >>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>> >>>>>>>> executing >>>>>>>> >>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>> >>>>>>>>>> When reading, Pickle code needs to know the layouts of a type >>>>>>>> >>>>>>>> both as >>>>>>>> >>>>>>>>>> it is on the reading machine and as it was on the machine that >>>>>>>> >>>>>>>> wrote >>>>>>>> >>>>>>>>>> the pickle. The type description that the compiler generates is >>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>> >>>>>>>> field >>>>>>>> >>>>>>>>>> types (which are either recursive type descriptions or builtin >>>>>>>> >>>>>>>> types). >>>>>>>> >>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>> >>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>> >>>>>>>> machine >>>>>>>> >>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>> >>>>>>>> description and >>>>>>>> >>>>>>>>>> simultaneously computes two sets of field displacements, both >>>>>>>> >>>>>>>> as they >>>>>>>> >>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>> >>>>>>>> the latter, >>>>>>>> >>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>> >>>>>>>> stored in the >>>>>>>> >>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>> >>>>>>>> techniques >>>>>>>> >>>>>>>>>> like >>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>> >>>>>>>> m3core, and >>>>>>>> >>>>>>>>>> called by Pickle code. >>>>>>>>>> >>>>>>>>>> This is very fragile. RTTipe has to duplicate the compiler's >>>>>>>> >>>>>>>> layout >>>>>>>> >>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>> >>>>>>>> involve >>>>>>>> >>>>>>>>>> quite a bit of rework, as the two use substantially different >>>>>>>> >>>>>>>> data >>>>>>>> >>>>>>>>>> structure and code organization. It will be obvious what kind >>>>>>>> >>>>>>>> of bit >>>>>>>> >>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>> >>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>> >>>>>>>> comparing the >>>>>>>> >>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>> >>>>>>>> compiler. The >>>>>>>> >>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>> >>>>>>>>>> Note that all this is required even without any packing of >>>>>>>> >>>>>>>> small fields >>>>>>>> >>>>>>>>>> within words. E.G., a record with two INTEGER fields, pickled >>>>>>>> >>>>>>>> on a >>>>>>>> >>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>> >>>>>>>>>> Tony Hosking wrote: >>>>>>>>>> >>>>>>>>>>> Rodney, >>>>>>>>>>> >>>>>>>>>>> Why does there need to be an entry for LONGINT in RTPacking? I >>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>> >>>>>>>> anyway. >>>>>>>> >>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>> >>>>>>>> figure >>>>>>>> >>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>> >>>>>>>> INTEGER is >>>>>>>> >>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I missing >>>>>>>>>>> something? >>>>>>>>>>> >>>>>>>>>>> -- Tony >>>>>>>>>>> >>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>>>>>> >>>>>>>> help with? >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>> 2) Variable length values of subrange bounds found in type >>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>> >>>>>>>> recently) >>>>>>>> >>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>> >>>>>>>>>>>>> I have done some coding on this, but have been interrupted. >>>>>>>>>>>>> >>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------- >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> > > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 16:40:44 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 09:40:44 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> References: <200802211055.m1LAt50C054353@camembert.async.caltech.edu> Message-ID: <47BEECFC.8060308@wichita.edu> I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable for another, more serious reason, namely, that the byte ordering of type signatures in the files is different. I think this can be fixed by making pickle code try either byte ordering, without invalidating any existing pickle files. There would be a very remote chance of a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. Mika Nystrom wrote: > Ugh!!! I am still using compilers that are almost ten years old > on ALL my systems just because I need to share pickles between them > and CM3 has a different TEXT format from my ancient PM3. Tony > thinks there's a workaround with specials but I haven't had a chance > to get to it yet... > > > -- ------------------------------------------------------------- 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 darko at darko.org Fri Feb 22 16:33:47 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 02:33:47 +1100 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BEE918.1060908@wichita.edu> References: <47BEE918.1060908@wichita.edu> Message-ID: <1E474378-253C-4484-813B-A747EF28051B@darko.org> I don't think breaking pickles is at issue at all since the alignment issues don't change the meaning of a type, only its layout in memory on a particular platform, akin to endian issues. On 23/02/2008, at 2:24 AM, Rodney M. Bates wrote: > This didn't appear to come through to the list the first time: > > -------- Original Message -------- > Subject: Re: [M3devel] <*LAZYALIGN*> > Date: Mon, 18 Feb 2008 20:11:17 -0600 > From: Rodney M. Bates > To: Randy Coleburn > CC: m3devel at elegosoft.com > References: <47AF72B5.2080308 at wichita.edu> > <47B1168F.8020302 at wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236 at darko.org > > <47B4C70D.4010408 at wichita.edu> <7323567C-7632-4040-B858-47B8124759DC at cs.purdue.edu > > <47B50EDF.8060807 at wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843 at cs.purdue.edu > > <47B5FB13.7070407 at wichita.edu > > <20080215223205.t9a01icx4okgco0o at mail.elegosoft.com> <47B60CE0.8050506 at wichita.edu > > <47B9644F.1E75.00D7.1 at scires.com> > > Just to clarify: I don't believe anything existing has to break. The > worst scenario I can see is that you would have to either > simultaneously > upgrade the compiler, libm3, and libm3core (or else none of these) > before > recompiling & linking any code that reads or writes pickles. If > libm3 and > libm3core are dynamically linked in at runtime, you would have to > recompile > with an upgraded compiler at the same time as installing the upgraded > dynamic libraries. > > Existing pickle files would not change. Also, mixtures of programs > thus > recompiled & linked and programs not recompiled/linked could > exchange pickle > files. > > Anything that (un)pickles records or objects that are LAZYALIGN > would need > the upgrade to work, but such programs are already broken. > > Randy Coleburn wrote: >> I use pickles extensively and they are used also by network objects. >> I've never used LAZYALIGN. >> My vote is that we don't break something (pickles/netobj) to add >> support for something that is rarely used. >> Regards, >> Randy > -- > ------------------------------------------------------------- > 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 > > > -- > ------------------------------------------------------------- > 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 darko at darko.org Fri Feb 22 16:38:29 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 02:38:29 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BEEBB3.6000800@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> Message-ID: I think you may be reading that definition too literally. Any processor is going to data alignment rules so 'adjacent' is subject to what can be implemented on the processor. The problem I have is that the existing code doesn't pack to the limits of the processor, but to some arbitrary alignment. Thus my comment about viewing so-called lazy alignment as a fix to an alignment bug. On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > > > Darko wrote: >> There wouldn't be any explicit expression. in the source, but >> there would be a flag in Target.i3 for turning it off and on for >> different platforms. >> Although the details may be a bit off, the principal is this: >> before byte alignment change: >> RECORD >> a: BITS 8 FOR 0..255; (* takes 32 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) > > ^If the compiler's alignment rules are not lazy, then this violates > a language rule and should not compile. From 2.2.5, Packed types: > > "...variables of type T that occur in records, objects, or arrays will > occupy exactly n bits and be packed adjacent to the preceding field or > element." > > To get the padding between a and b, you would have to either put it in > with an explicit pad field, or remove the BITS 32 from the type of b. > >> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >> END; >> after byte alignment change: >> RECORD >> a: BITS 8 FOR 0..255; (* takes 8 bits *) >> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >> END; >> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >>> Thanks for the explanation! How does one express the alignment >>> you support? >>> >>> It does sound like <*LAZYALIGN*> can go away. >>> >>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>> >>>> Actually rather than compilain rather grumpily, maybe I can just >>>> make the >>>> changes required to RTTipe and do the work to reomve the pragma. >>>> I can >>>> work with Randy to ensure it doesn't break pickles, there is no >>>> reason why >>>> it should. >>>> >>>> On tha subject Randy, I assume pickles encode the number of BITS >>>> FOR >>>> for a field? If not it should. >>>> >>>> >>>>> We seem to be going through these same point several times. I'm >>>>> not sure >>>>> what the difficulty is, I'm just repeating myself. >>>>> >>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>> FOR or bit >>>>> fields. >>>>> >>>>> The change I put in libralised the *M3* alignment rules so that >>>>> BITS FOR >>>>> fields in structures would align on byte boundries if possible >>>>> instead of >>>>> restricting them to word alignment generally. GCC happily >>>>> generates code >>>>> for this. There may be restrictions in GCC's C as to how you >>>>> can arrange >>>>> bit fields but I don't see what they have to do with M3. >>>>> >>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>> X and its >>>>> removal would make M3 pointless for use on the Mac, at least >>>>> more me. >>>>> >>>>> This should be the default behviour. If you are using BITS FOR >>>>> it's >>>>> becuase you want to arrange the fields in a record in >>>>> particular way. Why >>>>> then arbitrarliy pad out the fields? If performance is an >>>>> issue, the user >>>>> should be using appropriate field bit sizes. The implementation >>>>> rule for >>>>> BITS FOR in M3 is implementation dependent, there are no >>>>> language issues. >>>>> >>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>> Olaf >>>>> created and had nothing to do with me. I diagreed with it and >>>>> never used >>>>> it in the version of the compiler I ran. I support its removal. >>>>> >>>>> >>>>> >>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>> >>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>> for it. >>>>>>> >>>>>>> The PRGAMA is of no use and can be removed. >>>>>>> >>>>>>> Does anyone have any objections to making this alignment >>>>>>> behaviour >>>>>>> standard? >>>>>> >>>>>> >>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>> with >>>>>> the standard gcc-backend alignment? Perhaps I don't >>>>>> understand what >>>>>> it is you are doing or trying to do. Again, please remind me >>>>>> what it >>>>>> is that LAZYALIGN does and why it is needed. >>>>>> >>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>> >>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>> with >>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>> would >>>>>>>> argue to abandon it. >>>>>>>> >>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>> >>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>> objects. >>>>>>>>> I've never used LAZYALIGN. >>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>> add >>>>>>>>> support for something that is rarely used. >>>>>>>>> Regards, >>>>>>>>> Randy >>>>>>>>> >>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>> >>>>>>>>> PM >>> >>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>> to >>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>> without >>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>> existing >>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>> >>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>> >>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>> variables of that type. >>>>>>>>> >>>>>>>>> Olaf Wagner wrote: >>>>>>>>> >>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>> the >>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>> >>>>>>>>>> Olaf >>>>>>>>>> >>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>> >>>>>>>>> LAZYALIGN. >>>>>>>>> >>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>> pickles. >>>>>>>>>> >>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>> >>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>> Using >>>>>>>>> >>>>>>>>> BITSIZE, >>>>>>>>> >>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>> >>>>>>>>> executing >>>>>>>>> >>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>> >>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>> type >>>>>>>>> >>>>>>>>> both as >>>>>>>>> >>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>> that >>>>>>>>> >>>>>>>>> wrote >>>>>>>>> >>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>> generates is >>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>> >>>>>>>>> field >>>>>>>>> >>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>> builtin >>>>>>>>> >>>>>>>>> types). >>>>>>>>> >>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>> >>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>> >>>>>>>>> machine >>>>>>>>> >>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>> >>>>>>>>> description and >>>>>>>>> >>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>> both >>>>>>>>> >>>>>>>>> as they >>>>>>>>> >>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>> >>>>>>>>> the latter, >>>>>>>>> >>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>> >>>>>>>>> stored in the >>>>>>>>> >>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>> >>>>>>>>> techniques >>>>>>>>> >>>>>>>>>>> like >>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>> >>>>>>>>> m3core, and >>>>>>>>> >>>>>>>>>>> called by Pickle code. >>>>>>>>>>> >>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>> compiler's >>>>>>>>> >>>>>>>>> layout >>>>>>>>> >>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>> >>>>>>>>> involve >>>>>>>>> >>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>> different >>>>>>>>> >>>>>>>>> data >>>>>>>>> >>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>> kind >>>>>>>>> >>>>>>>>> of bit >>>>>>>>> >>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>> >>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>> >>>>>>>>> comparing the >>>>>>>>> >>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>> >>>>>>>>> compiler. The >>>>>>>>> >>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>> >>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>> >>>>>>>>> small fields >>>>>>>>> >>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>> pickled >>>>>>>>> >>>>>>>>> on a >>>>>>>>> >>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>> >>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>> >>>>>>>>>>>> Rodney, >>>>>>>>>>>> >>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>> RTPacking? I >>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>> >>>>>>>>> anyway. >>>>>>>>> >>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>> >>>>>>>>> figure >>>>>>>>> >>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>> >>>>>>>>> INTEGER is >>>>>>>>> >>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>> missing >>>>>>>>>>>> something? >>>>>>>>>>>> >>>>>>>>>>>> -- Tony >>>>>>>>>>>> >>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>> can >>>>>>>>> >>>>>>>>> help with? >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>> type >>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>> >>>>>>>>> recently) >>>>>>>>> >>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------- >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> > > -- > ------------------------------------------------------------- > 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 mika at async.caltech.edu Fri Feb 22 22:19:15 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 22 Feb 2008 13:19:15 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> Message-ID: <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> Oh I should be clear on what I mean, exactly, when I say things like that. Pickles "version 1", what was in SRC M3 and is in PM3, were never from what I understand completely implemented? For one thing, they didn't support endian-switching. A gentleman with a Scottish name that eludes me at the moment came out with "Pickles version 2", which do the endianness-switching, among other things. My "PM3" includes a lot of things from newer M3s, such as this Pickles version 2. I really am not enamored with my ancient PM3. I just need something that works reliably on Cygwin *and* FreeBSD (which it does). So adding the odd CM3 library to it is no big deal. But the TEXT issue is so deeply embedded in the compiler and runtime that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or vice versa. I am almost certain I have tested interchanging pickles between my PM3 code and some CM3 code and verified that it did work as long as there were no TEXTs involved. (It was a couple of years ago I did this; I think I spammed m3devel about it then too.) Mika "Rodney M. Bates" writes: >I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable >for another, more serious reason, namely, that the byte ordering of type >signatures in the files is different. > >I think this can be fixed by making pickle code try either byte ordering, without >invalidating any existing pickle files. There would be a very remote chance of >a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. > >Mika Nystrom wrote: >> Ugh!!! I am still using compilers that are almost ten years old >> on ALL my systems just because I need to share pickles between them >> and CM3 has a different TEXT format from my ancient PM3. Tony >> thinks there's a workaround with specials but I haven't had a chance >> to get to it yet... >> >> >> >-- >------------------------------------------------------------- >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 mika at async.caltech.edu Fri Feb 22 22:20:52 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 22 Feb 2008 13:20:52 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Sat, 23 Feb 2008 02:38:29 +1100." Message-ID: <200802222120.m1MLKqbK010997@camembert.async.caltech.edu> Hmm, can't you always write code to force whatever bit pattern you like, if you absolutely insist on it? One could read the specification that way too. Mika Darko writes: >I think you may be reading that definition too literally. Any >processor is going to data alignment rules so 'adjacent' is subject to >what can be implemented on the processor. The problem I have is that >the existing code doesn't pack to the limits of the processor, but to >some arbitrary alignment. Thus my comment about viewing so-called lazy >alignment as a fix to an alignment bug. > > >On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > >> >> >> Darko wrote: >>> There wouldn't be any explicit expression. in the source, but >>> there would be a flag in Target.i3 for turning it off and on for >>> different platforms. >>> Although the details may be a bit off, the principal is this: >>> before byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> >> ^If the compiler's alignment rules are not lazy, then this violates >> a language rule and should not compile. From 2.2.5, Packed types: >> >> "...variables of type T that occur in records, objects, or arrays will >> occupy exactly n bits and be packed adjacent to the preceding field or >> element." >> >> To get the padding between a and b, you would have to either put it in >> with an explicit pad field, or remove the BITS 32 from the type of b. >> >>> c: BITS 16 FOR 0..65000; (* takes 32 bits *) >>> END; >>> after byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 8 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >>> c: BITS 16 FOR 0..65000; (* takes 16 bits *) >>> END; >>> On 19/02/2008, at 3:40 PM, Tony Hosking wrote: >>>> Thanks for the explanation! How does one express the alignment >>>> you support? >>>> >>>> It does sound like <*LAZYALIGN*> can go away. >>>> >>>> On Feb 18, 2008, at 8:44 PM, Darko wrote: >>>> >>>>> Actually rather than compilain rather grumpily, maybe I can just >>>>> make the >>>>> changes required to RTTipe and do the work to reomve the pragma. >>>>> I can >>>>> work with Randy to ensure it doesn't break pickles, there is no >>>>> reason why >>>>> it should. >>>>> >>>>> On tha subject Randy, I assume pickles encode the number of BITS >>>>> FOR >>>>> for a field? If not it should. >>>>> >>>>> >>>>>> We seem to be going through these same point several times. I'm >>>>>> not sure >>>>>> what the difficulty is, I'm just repeating myself. >>>>>> >>>>>> Keep in mind this applies *only* to packed structures, ie BIT >>>>>> FOR or bit >>>>>> fields. >>>>>> >>>>>> The change I put in libralised the *M3* alignment rules so that >>>>>> BITS FOR >>>>>> fields in structures would align on byte boundries if possible >>>>>> instead of >>>>>> restricting them to word alignment generally. GCC happily >>>>>> generates code >>>>>> for this. There may be restrictions in GCC's C as to how you >>>>>> can arrange >>>>>> bit fields but I don't see what they have to do with M3. >>>>>> >>>>>> This is absolutely essentail for using the native APIs on Mac OS >>>>>> X and its >>>>>> removal would make M3 pointless for use on the Mac, at least >>>>>> more me. >>>>>> >>>>>> This should be the default behviour. If you are using BITS FOR >>>>>> it's >>>>>> becuase you want to arrange the fields in a record in >>>>>> particular way. Why >>>>>> then arbitrarliy pad out the fields? If performance is an >>>>>> issue, the user >>>>>> should be using appropriate field bit sizes. The implementation >>>>>> rule for >>>>>> BITS FOR in M3 is implementation dependent, there are no >>>>>> language issues. >>>>>> >>>>>> The LAZYALIGN pragma (that is, the prgama itself) is something >>>>>> Olaf >>>>>> created and had nothing to do with me. I diagreed with it and >>>>>> never used >>>>>> it in the version of the compiler I ran. I support its removal. >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote: >>>>>>> >>>>>>>> The alignment behaviour is absolutely crucial to programming >>>>>>>> natively in Mac OS X and should be kept. I have a great need >>>>>>>> for it. >>>>>>>> >>>>>>>> The PRGAMA is of no use and can be removed. >>>>>>>> >>>>>>>> Does anyone have any objections to making this alignment >>>>>>>> behaviour >>>>>>>> standard? >>>>>>> >>>>>>> >>>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go >>>>>>> with >>>>>>> the standard gcc-backend alignment? Perhaps I don't >>>>>>> understand what >>>>>>> it is you are doing or trying to do. Again, please remind me >>>>>>> what it >>>>>>> is that LAZYALIGN does and why it is needed. >>>>>>> >>>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >>>>>>>> >>>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur >>>>>>>>> with >>>>>>>>> Randy that if it is rarely used and moreso breaks things I >>>>>>>>> would >>>>>>>>> argue to abandon it. >>>>>>>>> >>>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>>>>>>>> >>>>>>>>>> I use pickles extensively and they are used also by network >>>>>>>>>> objects. >>>>>>>>>> I've never used LAZYALIGN. >>>>>>>>>> My vote is that we don't break something (pickles/netobj) to >>>>>>>>>> add >>>>>>>>>> support for something that is rarely used. >>>>>>>>>> Regards, >>>>>>>>>> Randy >>>>>>>>>> >>>>>>>>>>>>> "Rodney M. Bates" 2/15/2008 5:06 >>>>>>>>>> >>>>>>>>>> PM >>> >>>>>>>>>> I'll put it in comments in the code. I am sure I can fix it >>>>>>>>>> to >>>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it >>>>>>>>>> without >>>>>>>>>> requiring existing pickle files to be regenerated and/or >>>>>>>>>> existing >>>>>>>>>> code that reads/writes pickles to need recompilation. >>>>>>>>>> >>>>>>>>>> Anybody on this list who has code that might be affected if >>>>>>>>>> pickles >>>>>>>>> or compiled code were invalidated by a change? >>>>>>>>>> >>>>>>>>>> I do propose we change the way of telling the compiler to do >>>>>>>>>> LAZYALIGN so that it is a property of a type and affects all >>>>>>>>>> variables of that type. >>>>>>>>>> >>>>>>>>>> Olaf Wagner wrote: >>>>>>>>>> >>>>>>>>>>> Perhaps we should check-in this description somewhere near >>>>>>>>>>> the >>>>>>>>>>> actual code? Or is there enough documentation already? >>>>>>>>>>> >>>>>>>>>>> Olaf >>>>>>>>>>> >>>>>>>>>>> PS: Based on your description, I'd say we should abandon >>>>>>>>>> >>>>>>>>>> LAZYALIGN. >>>>>>>>>> >>>>>>>>>>> Or at least put a big sticker on that it will break >>>>>>>>>>> pickles. >>>>>>>>>>> >>>>>>>>>>> Quoting "Rodney M. Bates" : >>>>>>>>>>> >>>>>>>>>>>> The word "Packing" in RTPacking is perhaps misleading. >>>>>>>>>>>> Using >>>>>>>>>> >>>>>>>>>> BITSIZE, >>>>>>>>>> >>>>>>>>>>>> etc. only works for getting object layouts as on the machine >>>>>>>>>> >>>>>>>>>> executing >>>>>>>>>> >>>>>>>>>>>> the code, which is all that is needed when writing a pickle. >>>>>>>>>>>> >>>>>>>>>>>> When reading, Pickle code needs to know the layouts of a >>>>>>>>>>>> type >>>>>>>>>> >>>>>>>>>> both as >>>>>>>>>> >>>>>>>>>>>> it is on the reading machine and as it was on the machine >>>>>>>>>>>> that >>>>>>>>>> >>>>>>>>>> wrote >>>>>>>>>> >>>>>>>>>>>> the pickle. The type description that the compiler >>>>>>>>>>>> generates is >>>>>>>>>>>> excerpted and contains no field displacements, just lists of >>>>>>>>>> >>>>>>>>>> field >>>>>>>>>> >>>>>>>>>>>> types (which are either recursive type descriptions or >>>>>>>>>>>> builtin >>>>>>>>>> >>>>>>>>>> types). >>>>>>>>>> >>>>>>>>>>>> So it is independent of word sizes, etc. >>>>>>>>>>>> >>>>>>>>>>>> Pickles regenerates the displacements using the few target >>>>>>>>>> >>>>>>>>>> machine >>>>>>>>>> >>>>>>>>>>>> characteristics in a RTPacking.T It traverses a type >>>>>>>>>> >>>>>>>>>> description and >>>>>>>>>> >>>>>>>>>>>> simultaneously computes two sets of field displacements, >>>>>>>>>>>> both >>>>>>>>>> >>>>>>>>>> as they >>>>>>>>>> >>>>>>>>>>>> are on the reading machine and on the writing machine. For >>>>>>>>>> >>>>>>>>>> the latter, >>>>>>>>>> >>>>>>>>>>>> the value of RTPacking.T is (after a compact bit encoding) >>>>>>>>>> >>>>>>>>>> stored in the >>>>>>>>>> >>>>>>>>>>>> header of the pickle file. For the former, it's gotten by >>>>>>>>>> >>>>>>>>>> techniques >>>>>>>>>> >>>>>>>>>>>> like >>>>>>>>>>>> using BITSIZE. This is actually all done in RTTipe, part of >>>>>>>>>> >>>>>>>>>> m3core, and >>>>>>>>>> >>>>>>>>>>>> called by Pickle code. >>>>>>>>>>>> >>>>>>>>>>>> This is very fragile. RTTipe has to duplicate the >>>>>>>>>>>> compiler's >>>>>>>>>> >>>>>>>>>> layout >>>>>>>>>> >>>>>>>>>>>> behavior. There is no shared code. Making it common would >>>>>>>>>> >>>>>>>>>> involve >>>>>>>>>> >>>>>>>>>>>> quite a bit of rework, as the two use substantially >>>>>>>>>>>> different >>>>>>>>>> >>>>>>>>>> data >>>>>>>>>> >>>>>>>>>>>> structure and code organization. It will be obvious what >>>>>>>>>>>> kind >>>>>>>>>> >>>>>>>>>> of bit >>>>>>>>>> >>>>>>>>>>>> damage could occur if the two algorithms didn't agree. >>>>>>>>>>>> >>>>>>>>>>>> This is why I am obsessing over LAZYALIGN. I have been >>>>>>>>>> >>>>>>>>>> comparing the >>>>>>>>>> >>>>>>>>>>>> field displacement computations in RTTipe and in the >>>>>>>>>> >>>>>>>>>> compiler. The >>>>>>>>>> >>>>>>>>>>>> former is oblivious to LAZYALIGN. >>>>>>>>>>>> >>>>>>>>>>>> Note that all this is required even without any packing of >>>>>>>>>> >>>>>>>>>> small fields >>>>>>>>>> >>>>>>>>>>>> within words. E.G., a record with two INTEGER fields, >>>>>>>>>>>> pickled >>>>>>>>>> >>>>>>>>>> on a >>>>>>>>>> >>>>>>>>>>>> 32-bit machine and unpickled on a 64. >>>>>>>>>>>> >>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Rodney, >>>>>>>>>>>>> >>>>>>>>>>>>> Why does there need to be an entry for LONGINT in >>>>>>>>>>>>> RTPacking? I >>>>>>>>>>>>> would have thought all packing is done on word-sized units >>>>>>>>>> >>>>>>>>>> anyway. >>>>>>>>>> >>>>>>>>>>>>> Each side of the connection can check BITSIZE(LONGINT) to >>>>>>>>>> >>>>>>>>>> figure >>>>>>>>>> >>>>>>>>>>>>> out what to do presumably no differently from the way >>>>>>>>>> >>>>>>>>>> INTEGER is >>>>>>>>>> >>>>>>>>>>>>> communicated between 32-bit and 64-bit machines. Am I >>>>>>>>>>>>> missing >>>>>>>>>>>>> something? >>>>>>>>>>>>> >>>>>>>>>>>>> -- Tony >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Ah, OK. I don't much delve in pickle-land. Anything I >>>>>>>>>>>>>> can >>>>>>>>>> >>>>>>>>>> help with? >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) RTPacking.T and needs to have a separate size for >>>>>>>>>>>>>>> LONGINT, >>>>>>>>>>>>>>> (which can vary independently of the size of INTEGER). >>>>>>>>>>>>>>> 2) Variable length values of subrange bounds found in >>>>>>>>>>>>>>> type >>>>>>>>>>>>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>>>>>>>>>>>> what the native word size can represent. >>>>>>>>>>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>>>>>>>> >>>>>>>>>> recently) >>>>>>>>>> >>>>>>>>>>>>>>> is not handled by Pickles. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have done some coding on this, but have been >>>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tony Hosking wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Why is LONGINT for pickles not yet supported? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >> >> -- >> ------------------------------------------------------------- >> 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 rodney.bates at wichita.edu Fri Feb 22 22:49:33 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 15:49:33 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> Message-ID: <47BF436D.9080608@wichita.edu> No, this is exactly what the language says and means. However, there is more, in the same section that I took for granted: "The values allowed for n are implementation-dependent. An illegal value for n is a static error. The legality of a packed type can depend on its context; for example, an implementation could prohibit packed integers from spanning word boundaries." In other words, the compiler must either locate a packed field with no preceding padding, or else emit an error, and this is what both PM3 and CM3 do. LAZYALIGN weakens the CM3's restrictions and changes the handling of your example from a a compile error to respecting the no-padding rule. Either way is consistent with the language. Darko wrote: > I think you may be reading that definition too literally. Any processor > is going to data alignment rules so 'adjacent' is subject to what can > be implemented on the processor. The problem I have is that the > existing code doesn't pack to the limits of the processor, but to some > arbitrary alignment. Thus my comment about viewing so-called lazy > alignment as a fix to an alignment bug. > > > On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: > >> >> >> Darko wrote: >> >>> There wouldn't be any explicit expression. in the source, but there >>> would be a flag in Target.i3 for turning it off and on for >>> different platforms. >>> Although the details may be a bit off, the principal is this: >>> before byte alignment change: >>> RECORD >>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >> >> >> ^If the compiler's alignment rules are not lazy, then this violates >> a language rule and should not compile. From 2.2.5, Packed types: >> >> "...variables of type T that occur in records, objects, or arrays will >> occupy exactly n bits and be packed adjacent to the preceding field or >> element." >> >> To get the padding between a and b, you would have to either put it in >> with an explicit pad field, or remove the BITS 32 from the type of b. >> -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 22 23:01:16 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 16:01:16 -0600 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <1E474378-253C-4484-813B-A747EF28051B@darko.org> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> Message-ID: <47BF462C.6060204@wichita.edu> But pickles are working below the type safety of the language, copying bits around. True, pickles will only build an object in the reading program with the same type it had in the writing program. But the layout of fields can be different, even with the same type, for example, due to integer size, or as you say, endianness. Pickles has to be able to reconstruct the bit layout of a type both as it was on the writing machine and as it is on the reading machine. If anything LAZYALIGN is written to a pickle, then it's already broken, because pickles will have the wrong idea about where the bits of the fields are located and will garble bits. Pickles always recomputes bit layouts as the compiler would for STRICTALIGN. Which means, if you never pickle anything that is LAZYALIGN, you won't invoke this brokenness. And it sounds like nobody is doing that, so it's not broken for current uses. Darko wrote: > I don't think breaking pickles is at issue at all since the alignment > issues don't change the meaning of a type, only its layout in memory on > a particular platform, akin to endian issues. > >-- ------------------------------------------------------------- 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 rcoleburn at scires.com Sat Feb 23 01:16:36 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 22 Feb 2008 19:16:36 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> References: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> Message-ID: <47BF1F8F.1E75.00D7.1@scires.com> Mika: I believe the person you are referencing is Blair McIntyre. Last time I communicated with him he was a professor at Georgia Tech. Regards, Randy >>> Mika Nystrom 2/22/2008 4:19 PM >>> Oh I should be clear on what I mean, exactly, when I say things like that. Pickles "version 1", what was in SRC M3 and is in PM3, were never from what I understand completely implemented? For one thing, they didn't support endian-switching. A gentleman with a Scottish name that eludes me at the moment came out with "Pickles version 2", which do the endianness-switching, among other things. My "PM3" includes a lot of things from newer M3s, such as this Pickles version 2. I really am not enamored with my ancient PM3. I just need something that works reliably on Cygwin *and* FreeBSD (which it does). So adding the odd CM3 library to it is no big deal. But the TEXT issue is so deeply embedded in the compiler and runtime that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or vice versa. I am almost certain I have tested interchanging pickles between my PM3 code and some CM3 code and verified that it did work as long as there were no TEXTs involved. (It was a couple of years ago I did this; I think I spammed m3devel about it then too.) Mika "Rodney M. Bates" writes: >I believe from reading code, that PM3 and CM3 pickle files are non-interchangeable >for another, more serious reason, namely, that the byte ordering of type >signatures in the files is different. > >I think this can be fixed by making pickle code try either byte ordering, without >invalidating any existing pickle files. There would be a very remote chance of >a misrecognized type, but then this is already possible due to the hash-code nature of signatures anyway. This is on my to-do list for work on pickles. > >Mika Nystrom wrote: >> Ugh!!! I am still using compilers that are almost ten years old >> on ALL my systems just because I need to share pickles between them >> and CM3 has a different TEXT format from my ancient PM3. Tony >> thinks there's a workaround with specials but I haven't had a chance >> to get to it yet... >> >> >> >-- >------------------------------------------------------------- >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 rcoleburn at scires.com Sat Feb 23 01:21:05 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 22 Feb 2008 19:21:05 -0500 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BF462C.6060204@wichita.edu> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> Message-ID: <47BF209D.1E75.00D7.1@scires.com> I agree with Rodney. Regards, Randy >>> "Rodney M. Bates" 2/22/2008 5:01 PM >>> But pickles are working below the type safety of the language, copying bits around. True, pickles will only build an object in the reading program with the same type it had in the writing program. But the layout of fields can be different, even with the same type, for example, due to integer size, or as you say, endianness. Pickles has to be able to reconstruct the bit layout of a type both as it was on the writing machine and as it is on the reading machine. If anything LAZYALIGN is written to a pickle, then it's already broken, because pickles will have the wrong idea about where the bits of the fields are located and will garble bits. Pickles always recomputes bit layouts as the compiler would for STRICTALIGN. Which means, if you never pickle anything that is LAZYALIGN, you won't invoke this brokenness. And it sounds like nobody is doing that, so it's not broken for current uses. Darko wrote: > I don't think breaking pickles is at issue at all since the alignment > issues don't change the meaning of a type, only its layout in memory on > a particular platform, akin to endian issues. > >-- ------------------------------------------------------------- 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 darko at darko.org Sat Feb 23 02:01:55 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 12:01:55 +1100 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <47BF462C.6060204@wichita.edu> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> Message-ID: <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> Then I assume RTTipe needs to be fixed, and pickles and the alignment are ok. On 23/02/2008, at 9:01 AM, Rodney M. Bates wrote: > But pickles are working below the type safety of the language, copying > bits around. True, pickles will only build an object in the reading > program with the same type it had in the writing program. But the > layout of fields can be different, even with the same type, for > example, > due to integer size, or as you say, endianness. Pickles has to be > able > to reconstruct the bit layout of a type both as it was on the writing > machine and as it is on the reading machine. > > If anything LAZYALIGN is written to a pickle, then it's already > broken, > because pickles will have the wrong idea about where the bits of the > fields are located and will garble bits. Pickles always recomputes > bit layouts as the compiler would for STRICTALIGN. > > Which means, if you never pickle anything that is LAZYALIGN, you won't > invoke this brokenness. And it sounds like nobody is doing that, so > it's not broken for current uses. > > Darko wrote: >> I don't think breaking pickles is at issue at all since the >> alignment issues don't change the meaning of a type, only its >> layout in memory on a particular platform, akin to endian issues. >> -- > ------------------------------------------------------------- > 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 darko at darko.org Sat Feb 23 02:07:16 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 12:07:16 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF436D.9080608@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> Message-ID: <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> It's been several years since I looked at the code, so my recollection is obviously faulty. But this means that the actual change is a positive one, allowing more packings to be legal, and there is no need for any pragmas. So the new alignment rules would be that for any platform that allows it, allow fields to align on byte boundaries, except traced references that must be aligned on word boundaries. This would mean that a pickle packed on a platform with the more liberal alignment might be illegal on another platform. Therefore caution should be taken, otherwise I see no problem with this. On 23/02/2008, at 8:49 AM, Rodney M. Bates wrote: > No, this is exactly what the language says and means. However, > there is > more, in the same section that I took for granted: > > "The values allowed for n are implementation-dependent. An illegal > value for n is a > static error. The legality of a packed type can depend on its > context; for example, an > implementation could prohibit packed integers from spanning word > boundaries." > > In other words, the compiler must either locate a packed field with > no preceding > padding, or else emit an error, and this is what both PM3 and CM3 > do. LAZYALIGN > weakens the CM3's restrictions and changes the handling of your > example from a > a compile error to respecting the no-padding rule. Either way is > consistent with > the language. > > Darko wrote: >> I think you may be reading that definition too literally. Any >> processor is going to data alignment rules so 'adjacent' is subject >> to what can be implemented on the processor. The problem I have is >> that the existing code doesn't pack to the limits of the >> processor, but to some arbitrary alignment. Thus my comment about >> viewing so-called lazy alignment as a fix to an alignment bug. >> On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote: >>> >>> >>> Darko wrote: >>> >>>> There wouldn't be any explicit expression. in the source, but >>>> there would be a flag in Target.i3 for turning it off and on >>>> for different platforms. >>>> Although the details may be a bit off, the principal is this: >>>> before byte alignment change: >>>> RECORD >>>> a: BITS 8 FOR 0..255; (* takes 32 bits *) >>>> b: BITS 32 FOR INTEGER; (* takes 32 bits *) >>> >>> >>> ^If the compiler's alignment rules are not lazy, then this violates >>> a language rule and should not compile. From 2.2.5, Packed types: >>> >>> "...variables of type T that occur in records, objects, or arrays >>> will >>> occupy exactly n bits and be packed adjacent to the preceding >>> field or >>> element." >>> >>> To get the padding between a and b, you would have to either put >>> it in >>> with an explicit pad field, or remove the BITS 32 from the type of >>> b. >>> > > -- > ------------------------------------------------------------- > 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 rodney.bates at wichita.edu Sat Feb 23 05:07:38 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 22 Feb 2008 22:07:38 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> Message-ID: <47BF9C0A.8000804@wichita.edu> Darko wrote: > It's been several years since I looked at the code, so my recollection > is obviously faulty. But this means that the actual change is a > positive one, allowing more packings to be legal, and there is no need > for any pragmas. > > So the new alignment rules would be that for any platform that allows > it, allow fields to align on byte boundaries, except traced references > that must be aligned on word boundaries. > > This would mean that a pickle packed on a platform with the more > liberal alignment might be illegal on another platform. Therefore > caution should be taken, otherwise I see no problem with this. > > Actually, if RTTipe can detect this illegality, then it can just as easily make it legal and accommodate it, rearranging the fields to the new displacements. It already does this for other reasons anyway. The tricky design problem is how to communicate to RTTipe code, which rules were used. If a mix of different rules exists anywhere in the universe, either in different compilers or in the same compiler with different options, then it must be somehow encoded in a type description, as read by RTTipe, which rules were used. Otherwise, RTTipe not even detect this mismatch, and bits get shuffled. And do this without invalidating existing pickle files and existing compiled code (where the type descriptions are stored.) -- ------------------------------------------------------------- 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 darko at darko.org Sat Feb 23 06:33:13 2008 From: darko at darko.org (Darko) Date: Sat, 23 Feb 2008 16:33:13 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF9C0A.8000804@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> Message-ID: The alignment rules are particular to a platform, not a type (at least after we get rid of the pragma), so is there no field where we can encode some information about the platform in the pickle header or something? Where is endian stored? On 23/02/2008, at 3:07 PM, Rodney M. Bates wrote: > > > Darko wrote: >> It's been several years since I looked at the code, so my >> recollection is obviously faulty. But this means that the actual >> change is a positive one, allowing more packings to be legal, and >> there is no need for any pragmas. >> So the new alignment rules would be that for any platform that >> allows it, allow fields to align on byte boundaries, except traced >> references that must be aligned on word boundaries. >> This would mean that a pickle packed on a platform with the more >> liberal alignment might be illegal on another platform. Therefore >> caution should be taken, otherwise I see no problem with this. >> > Actually, if RTTipe can detect this illegality, then it can just > as easily make it legal and accommodate it, rearranging the fields > to the new displacements. It already does this for other reasons > anyway. > > The tricky design problem is how to communicate to RTTipe code, which > rules were used. If a mix of different rules exists anywhere in the > universe, either in different compilers or in the same compiler with > different options, then it must be somehow encoded in a type > description, > as read by RTTipe, which rules were used. Otherwise, RTTipe not > even detect > this mismatch, and bits get shuffled. And do this without > invalidating > existing pickle files and existing compiled code (where the type > descriptions are stored.) > -- > ------------------------------------------------------------- > 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 Sat Feb 23 11:14:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 10:14:49 +0000 Subject: [M3devel] response file changes? In-Reply-To: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: "response files" are files that contain command lines, to overcomecommand line length limits. (Why the limits are so small? Lame.) CM3 has built in support for them. I have seen them not be deleted reliably. While the deletion should be made more reliable, I propose they be writteninto the target directory instead of "temp". That is, nearly all writes should be into the target directory.This is what is reliably cleaned up when you run "realclean". I realize there is a tension between putting things that belong together together, and reliable deletion, vs. load balancing of I/O. "Temp" is sometimes smaller/faster. I had already worked around this by wrapping up the response file supportin Quake code that moves the file into the target directory immediatelyafter creating it. I'll be able to remove that code, and live with theunreliably deleted files only when using older tools. ? Also, the built in support uses a heuristic.For shorter command lines, it doesn't use a response file.I found that surprising and a bit disappointing.While a more immediately readable log is valuable, consistency is too. Leave it alone or make it always use a response file? The Microsoft C compiler and linker dump the output of any response filethey are given, so that gets you a readable log. I don't care all that much. Maybe I'll just look into why the deletion is unreliable, but I figure "cleanup" is always unreliable because you might control-c the build, or the compiler might crash, etc. There is a "delete on close" flag in Windows, but I think it has a problem in that you have to keep the file open and if anyone else also opens it, they might need file_share_delete, not sure. File_share_delete not being supported on Win9x, maybe not much used? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 12:04:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 12:04:46 +0100 Subject: [M3devel] response file changes? In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Two short comments: o Response files in the target directory should be OK, as long as their names are unique. o The heuristic is built-in to arglist(pfx, array), IIRC; I wouldn't change that without need. You never know what depends on it, as it has been there for a long time. Olaf Quoting Jay : > "response files" are files that contain command lines, to > overcomecommand line length limits. (Why the limits are so small? > Lame.) > CM3 has built in support for them. > I have seen them not be deleted reliably. > While the deletion should be made more reliable, I propose they be > writteninto the target directory instead of "temp". > That is, nearly all writes should be into the target directory.This > is what is reliably cleaned up when you run "realclean". > > I realize there is a tension between putting things that belong > together together, and reliable deletion, vs. load balancing of I/O. > "Temp" is sometimes smaller/faster. > I had already worked around this by wrapping up the response file > supportin Quake code that moves the file into the target directory > immediatelyafter creating it. I'll be able to remove that code, and > live with theunreliably deleted files only when using older tools. > ? > Also, the built in support uses a heuristic.For shorter command > lines, it doesn't use a response file.I found that surprising and a > bit disappointing.While a more immediately readable log is valuable, > consistency is too. > Leave it alone or make it always use a response file? > The Microsoft C compiler and linker dump the output of any response > filethey are given, so that gets you a readable log. > > I don't care all that much. > Maybe I'll just look into why the deletion is unreliable, but I > figure "cleanup" is always unreliable because you might control-c > the build, or the compiler might crash, etc. There is a "delete on > close" flag in Windows, but I think it has a problem in that you > have to keep the file open and if anyone else also opens it, they > might need file_share_delete, not sure. File_share_delete not being > supported on Win9x, maybe not much used? > > - Jay > _________________________________________________________________ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". > http://www.msnmobilefix.com/Default.aspx -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 12:59:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 11:59:46 +0000 Subject: [M3devel] paths.. In-Reply-To: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: I could be wrong about many things here: Cygwin fopen and I presume open accepts all of: c:\foo, c:/foo, /foo, \foo /foo and \foo probably have a different meaning between Cygwin and Win32. In Win32, /foo and \foo are, well, \foo, on the current drive. In Cygwin, /foo is probably /foo at the Cygwin root. I'd kind of like to be wrong here, about \foo having different meanings between them, since it a common form for me. Cygwin does not accept c:foo. In Win32 c:foo is foo in the current working directory of the C: drive. I don't think c:foo is used often, but it does have a meaning. Now, as well, cm3 has its own Path module, M3Path, but I realized tonight it also uses libm3's Pathname module a fair amount. In particular, I was having errors "shipping". This throws a big monkey wrench into where I was going. So now, after a bunch of going back and forth on various uncommited changes, I have now switched (and commited) NT386GNU to use PathnameWin32.m3. To some extent, this strikes at the core of "what is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". However, remember that Cygwin does appear to accept Win32 paths. So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that Win32 accepts /foo, is it Posix?) As well, this target still uses cygwin1.dll for its all its odd behaviors. It still uses open/read/write (again, remember that msvcrt.dll DOES expose these SAME functions..I still contend that Win32 is close enough to Posix to satisfy almost everyone..and then X Windows can be dealt with separately maybe, or Trestle/Win32 fixed). I have some more testing to do but I think this switch will fly, and various other options can go away. And I can undo the small amount I had commited. I think I'll just send my m3path.m3 diff around and then delete it. I ended up with a set based approach where host and target have a set of dir separaters, volume separaters, and separators (union of previous two). These are TINY sets, containing a maximum of three characters each, and '/' is always a member of two of them. So a set is kind of overkill. But it works out pretty ok. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 13:03:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 12:03:50 +0000 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: attached contains diffs and resulting files - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 23 Feb 2008 11:59:46 +0000Subject: [M3devel] paths.. I could be wrong about many things here: Cygwin fopen and I presume open accepts all of: c:\foo, c:/foo, /foo, \foo /foo and \foo probably have a different meaning between Cygwin and Win32.In Win32, /foo and \foo are, well, \foo, on the current drive.In Cygwin, /foo is probably /foo at the Cygwin root.I'd kind of like to be wrong here, about \foo having different meanings between them, since it a common form for me. Cygwin does not accept c:foo.In Win32 c:foo is foo in the current working directory of the C: drive.I don't think c:foo is used often, but it does have a meaning. Now, as well, cm3 has its own Path module, M3Path, but I realized tonight it also uses libm3's Pathname module a fair amount. In particular, I was having errors "shipping". This throws a big monkey wrench into where I was going.So now, after a bunch of going back and forth on various uncommited changes, I have now switched (and commited) NT386GNU to use PathnameWin32.m3. To some extent, this strikes at the core of "what is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". However, remember that Cygwin does appear to accept Win32 paths. So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that Win32 accepts /foo, is it Posix?) As well, this target still uses cygwin1.dll for its all its odd behaviors. It still uses open/read/write (again, remember that msvcrt.dll DOES expose these SAME functions..I still contend that Win32 is close enough to Posix to satisfy almost everyone..and then X Windows can be dealt with separately maybe, or Trestle/Win32 fixed). I have some more testing to do but I think this switch will fly, and various other options can go away.And I can undo the small amount I had commited.I think I'll just send my m3path.m3 diff around and then delete it. I ended up with a set based approach where host and target have a set of dir separaters, volume separaters, and separators (union of previous two). These are TINY sets, containing a maximum of three characters each, and '/' is always a member of two of them. So a set is kind of overkill. But it works out pretty ok. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: path.tar.gz Type: application/x-gzip Size: 49603 bytes Desc: not available URL: From wagner at elegosoft.com Sat Feb 23 13:39:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 13:39:09 +0100 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> Message-ID: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Jay, I'm not really happy with NT386GNU using PathnameWin32.m3. In my opininion it should just use the POSIX code, whatever problems people will have with their installation roots. (These can be avoided by using the /cygdrive/... equivalents.) Why don't we just assume that by deafult CM3 is installed in /usr/local/cm3 as for all other targets (except NT386, of course)? One thing that immediately comes to mind is that all paths output by CM3 programs will contain \ instead of / then and thus be unusable for simple copy-and-paste, as \ is the escape character in all POSIX command line tools. So this seems kind of incompatible to me. Olaf Quoting Jay : > I could be wrong about many things here: > > Cygwin fopen and I presume open accepts all of: > c:\foo, c:/foo, /foo, \foo > > /foo and \foo probably have a different meaning between Cygwin and Win32. > In Win32, /foo and \foo are, well, \foo, on the current drive. > In Cygwin, /foo is probably /foo at the Cygwin root. > I'd kind of like to be wrong here, about \foo having different > meanings between them, since it a common form for me. > > Cygwin does not accept c:foo. > In Win32 c:foo is foo in the current working directory of the C: drive. > I don't think c:foo is used often, but it does have a meaning. > > Now, as well, cm3 has its own Path module, M3Path, but I realized > tonight it also uses libm3's Pathname module a fair amount. In > particular, I was having errors "shipping". > > This throws a big monkey wrench into where I was going. > So now, after a bunch of going back and forth on various uncommited > changes, I have now switched (and commited) NT386GNU to use > PathnameWin32.m3. To some extent, this strikes at the core of "what > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > However, remember that Cygwin does appear to accept Win32 paths. > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > Win32 accepts /foo, is it Posix?) As well, this target still uses > cygwin1.dll for its all its odd behaviors. It still uses > open/read/write (again, remember that msvcrt.dll DOES expose these > SAME functions..I still contend that Win32 is close enough to Posix > to satisfy almost everyone..and then X Windows can be dealt with > separately maybe, or Trestle/Win32 fixed). > > I have some more testing to do but I think this switch will fly, and > various other options can go away. > And I can undo the small amount I had commited. > I think I'll just send my m3path.m3 diff around and then delete it. > > I ended up with a set based approach where host and target have a > set of dir separaters, volume separaters, and separators (union of > previous two). These are TINY sets, containing a maximum of three > characters each, and '/' is always a member of two of them. So a set > is kind of overkill. But it works out pretty ok. > > - Jay > _________________________________________________________________ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". > http://www.msnmobilefix.com/Default.aspx -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 14:07:09 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:07:09 +0000 Subject: [M3devel] paths.. In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: They'll be escaped.?Olaf, I'm just not sure. It could be that if I just set CM3_ROOT, CM3_INSTALL, and possibly M3_CONFIG, then the Posix code is ok. However, note as I said that Cygwin does accept these paths..The opposite problem holds too -- I like copy/pasting the error messages into file.open dialogs, and forward slashes don't work there unfortunately. I had a diff for a bit that between \ and /, would try to use whatever was already in the data. I had a problem with but it still might be viable, specifically in the Win32 paths. Maybe if I can just get it definitely usable (maybe already there) and get a distribution out, someone else can hack on this issue.. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Jay,> > I'm not really happy with NT386GNU using PathnameWin32.m3.> In my opininion it should just use the POSIX code, whatever problems> people will have with their installation roots. (These can be avoided> by using the /cygdrive/... equivalents.)> Why don't we just assume that by deafult CM3 is installed in> /usr/local/cm3 as for all other targets (except NT386, of course)?> > One thing that immediately comes to mind is that all paths output> by CM3 programs will contain \ instead of / then and thus be> unusable for simple copy-and-paste, as \ is the escape character> in all POSIX command line tools. So this seems kind of incompatible> to me.> > Olaf> > Quoting Jay :> > > I could be wrong about many things here:> >> > Cygwin fopen and I presume open accepts all of:> > c:\foo, c:/foo, /foo, \foo> >> > /foo and \foo probably have a different meaning between Cygwin and Win32.> > In Win32, /foo and \foo are, well, \foo, on the current drive.> > In Cygwin, /foo is probably /foo at the Cygwin root.> > I'd kind of like to be wrong here, about \foo having different > > meanings between them, since it a common form for me.> >> > Cygwin does not accept c:foo.> > In Win32 c:foo is foo in the current working directory of the C: drive.> > I don't think c:foo is used often, but it does have a meaning.> >> > Now, as well, cm3 has its own Path module, M3Path, but I realized > > tonight it also uses libm3's Pathname module a fair amount. In > > particular, I was having errors "shipping".> >> > This throws a big monkey wrench into where I was going.> > So now, after a bunch of going back and forth on various uncommited > > changes, I have now switched (and commited) NT386GNU to use > > PathnameWin32.m3. To some extent, this strikes at the core of "what > > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > > However, remember that Cygwin does appear to accept Win32 paths. > > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > > Win32 accepts /foo, is it Posix?) As well, this target still uses > > cygwin1.dll for its all its odd behaviors. It still uses > > open/read/write (again, remember that msvcrt.dll DOES expose these > > SAME functions..I still contend that Win32 is close enough to Posix > > to satisfy almost everyone..and then X Windows can be dealt with > > separately maybe, or Trestle/Win32 fixed).> >> > I have some more testing to do but I think this switch will fly, and > > various other options can go away.> > And I can undo the small amount I had commited.> > I think I'll just send my m3path.m3 diff around and then delete it.> >> > I ended up with a set based approach where host and target have a > > set of dir separaters, volume separaters, and separators (union of > > previous two). These are TINY sets, containing a maximum of three > > characters each, and '/' is always a member of two of them. So a set > > is kind of overkill. But it works out pretty ok.> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 14:30:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:30:28 +0000 Subject: [M3devel] bringing up NT386GNU a bit easier now In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: It is now a bit easier to bring up NT386GNU. (because of the path change mainly) Remember to remove spaces from start/ends of lines in my mail (they inhibit misformatting..email systems really stink these days..). Again, cm3cg.exe I had already, and sitting in an otherwise 5.1.8 tree so I set OMIT_GCC=yes rmdir /q/s \cm3 xcopy /fivery \cm3-min-WIN32-NT386-5.1.8 \cm3 Newer versions should of course work fine. c:\cm3\bin is in %PATH%: set PATH=c:\cygwin\bin;%PATH% Cygwin is in the %PATH%: set PATH=c:\cygwin\bin;%PATH% Remember to delete \cygwin\bin\link.exe and \cygwin\bin\cc.exe. Link.exe gets confused with the Visual C++ linker. cc.exe causes a crash in ntvdm.exe when building cm3cg (at least outside of Cygwin). gcc.exe works fine and suffices. vcvars32 has been run so cl.exe, link.exe are in %PATH%, %LIB%, and %INCLUDE% are set I'd actually like to simplify that, there is prototype code already in pylib.py. This is for bootstrapping. It shouldn't be needed once there is a binary distribution to start with. You should also be able to bootstrap from other hosts, but I haven't tried. No other variables are needed. No CM3_ROOT, CM3_INSTALL, or M3_CONFIG. First make sure you have an up to date NT386 toolset: cd C:\dev2\cm3.2\scripts\python upgrade.py once that finishes set CM3_OSTYPE=POSIX (again remember no trailing spaces..) do-cm3-all.py realclean do-cm3-front.py buildship install-cm3-compiler.py do-cm3-std.py buildship do-cm3-std will eventually hit a crash, but this is after it has gotten quite far. To verify you are really using Cygwin: findstr /i /m cygwin1.dll \cm3\bin\* \cm3\bin\cm3.exe (This is what means you are /using/ it, the others maybe aren't run.) \cm3\bin\arithmetic.dll \cm3\bin\BitVector.dll \cm3\bin\cm3cg.exe \cm3\bin\DiGraph.dll \cm3\bin\Geometry.dll \cm3\bin\m3.dll \cm3\bin\m3bundle.exe \cm3\bin\m3core.dll \cm3\bin\m3parseparams.dll \cm3\bin\m3slisp.dll \cm3\bin\mklib.exe \cm3\bin\patternmatching.dll \cm3\bin\set.dll \cm3\bin\SortedTableExtras.dll \cm3\bin\sysutils.dll \cm3\bin\table-list.dll \cm3\bin\TempFiles.dll Or watch .dll loads in a debugger: \bin\cdb \cm3\bin\cm3 ModLoad: 00400000 01212000 image00400000 ModLoad: 7c900000 7c9b0000 ntdll.dll ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll ModLoad: 61000000 61200000 C:\cygwin\bin\cygwin1.dll <<< ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL ModLoad: 77e70000 77f02000 C:\WINDOWS\system32\RPCRT4.dll - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 14:50:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 13:50:50 +0000 Subject: [M3devel] paths.. In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: I guess really this is why "I" will use NT386 or NT386MINGNU, and "you" will use NT386GNU. NT386GNU should be counter whatever I like. :) Ok, I'll try that again.. (So much for those instructions I just sent out, oh well; they are still correct but after some testing..may be invalidated..) I did find that Cygwin->cm3->quake->exec("c:\cm3\bin\m3bundle") doesn't work due to these annoying path issues... - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sat, 23 Feb 2008 13:07:09 +0000Subject: Re: [M3devel] paths.. They'll be escaped.?Olaf, I'm just not sure. It could be that if I just set CM3_ROOT, CM3_INSTALL, and possibly M3_CONFIG, then the Posix code is ok. However, note as I said that Cygwin does accept these paths..The opposite problem holds too -- I like copy/pasting the error messages into file.open dialogs, and forward slashes don't work there unfortunately.I had a diff for a bit that between \ and /, would try to use whatever was already in the data.I had a problem with but it still might be viable, specifically in the Win32 paths. Maybe if I can just get it definitely usable (maybe already there) and get a distribution out, someone else can hack on this issue.. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Jay,> > I'm not really happy with NT386GNU using PathnameWin32.m3.> In my opininion it should just use the POSIX code, whatever problems> people will have with their installation roots. (These can be avoided> by using the /cygdrive/... equivalents.)> Why don't we just assume that by deafult CM3 is installed in> /usr/local/cm3 as for all other targets (except NT386, of course)?> > One thing that immediately comes to mind is that all paths output> by CM3 programs will contain \ instead of / then and thus be> unusable for simple copy-and-paste, as \ is the escape character> in all POSIX command line tools. So this seems kind of incompatible> to me.> > Olaf> > Quoting Jay :> > > I could be wrong about many things here:> >> > Cygwin fopen and I presume open accepts all of:> > c:\foo, c:/foo, /foo, \foo> >> > /foo and \foo probably have a different meaning between Cygwin and Win32.> > In Win32, /foo and \foo are, well, \foo, on the current drive.> > In Cygwin, /foo is probably /foo at the Cygwin root.> > I'd kind of like to be wrong here, about \foo having different > > meanings between them, since it a common form for me.> >> > Cygwin does not accept c:foo.> > In Win32 c:foo is foo in the current working directory of the C: drive.> > I don't think c:foo is used often, but it does have a meaning.> >> > Now, as well, cm3 has its own Path module, M3Path, but I realized > > tonight it also uses libm3's Pathname module a fair amount. In > > particular, I was having errors "shipping".> >> > This throws a big monkey wrench into where I was going.> > So now, after a bunch of going back and forth on various uncommited > > changes, I have now switched (and commited) NT386GNU to use > > PathnameWin32.m3. To some extent, this strikes at the core of "what > > is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > > However, remember that Cygwin does appear to accept Win32 paths. > > So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > > Win32 accepts /foo, is it Posix?) As well, this target still uses > > cygwin1.dll for its all its odd behaviors. It still uses > > open/read/write (again, remember that msvcrt.dll DOES expose these > > SAME functions..I still contend that Win32 is close enough to Posix > > to satisfy almost everyone..and then X Windows can be dealt with > > separately maybe, or Trestle/Win32 fixed).> >> > I have some more testing to do but I think this switch will fly, and > > various other options can go away.> > And I can undo the small amount I had commited.> > I think I'll just send my m3path.m3 diff around and then delete it.> >> > I ended up with a set based approach where host and target have a > > set of dir separaters, volume separaters, and separators (union of > > previous two). These are TINY sets, containing a maximum of three > > characters each, and '/' is always a member of two of them. So a set > > is kind of overkill. But it works out pretty ok.> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 23 15:35:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 23 Feb 2008 09:35:49 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47BF1F8F.1E75.00D7.1@scires.com> References: Your message of "Fri, 22 Feb 2008 09:40:44 CST." <47BEECFC.8060308@wichita.edu> <200802222119.m1MLJFVx010910@camembert.async.caltech.edu> <47BF1F8F.1E75.00D7.1@scires.com> Message-ID: <8796B54C-B731-4042-9A86-D14368601CF9@cs.purdue.edu> Yes, Blair MacIntyre is still at GaTech: http://www.cc.gatech.edu/ ~blair/home.html. On Feb 22, 2008, at 7:16 PM, Randy Coleburn wrote: > Mika: > > I believe the person you are referencing is Blair McIntyre. Last > time I communicated with him he was a professor at Georgia Tech. > > Regards, > Randy > > >>> Mika Nystrom 2/22/2008 4:19 PM >>> > Oh I should be clear on what I mean, exactly, when I say things > like that. > > Pickles "version 1", what was in SRC M3 and is in PM3, were never > from what > I understand completely implemented? For one thing, they didn't > support > endian-switching. > > A gentleman with a Scottish name that eludes me at the moment came > out with "Pickles version 2", which do the endianness-switching, among > other things. > > My "PM3" includes a lot of things from newer M3s, such as this > Pickles version 2. > > I really am not enamored with my ancient PM3. I just need something > that works reliably on Cygwin *and* FreeBSD (which it does). So > adding > the odd CM3 library to it is no big deal. > > But the TEXT issue is so deeply embedded in the compiler and runtime > that I haven't had the guts to try to retrofit CM3 TEXTs to PM3 or > vice versa. > > I am almost certain I have tested interchanging pickles between my > PM3 code > and some CM3 code and verified that it did work as long as there > were no > TEXTs involved. (It was a couple of years ago I did this; I think > I spammed > m3devel about it then too.) > > Mika > > "Rodney M. Bates" writes: > >I believe from reading code, that PM3 and CM3 pickle files are non- > interchangeable > >for another, more serious reason, namely, that the byte ordering > of type > >signatures in the files is different. > > > >I think this can be fixed by making pickle code try either byte > ordering, without > >invalidating any existing pickle files. There would be a very > remote chance of > >a misrecognized type, but then this is already possible due to the > hash-code nature > of signatures anyway. This is on my to-do list for work on pickles. > > > >Mika Nystrom wrote: > >> Ugh!!! I am still using compilers that are almost ten years old > >> on ALL my systems just because I need to share pickles between them > >> and CM3 has a different TEXT format from my ancient PM3. Tony > >> thinks there's a workaround with specials but I haven't had a > chance > >> to get to it yet... > >> > >> > >> > >-- > >------------------------------------------------------------- > >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 Sat Feb 23 16:04:39 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:04:39 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: I see a lot of like: == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ --- building in NT386GNU --- ignoring ../src/m3overrides new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: synwr.lib--- shipping from NT386GNU --- This is mildly dumb. I should check as to why m3.lib changed, but an import .lib changing is rarely legitimate cause for a relink. As long as no symbols were added or removed, no relink is needed. Even then, it usually doesn't matter, but harder to tell. It's true the import .libs have "hints" as to "ordinals" but I don't think anyone cares about those. Definitely maybe the fix should be that when the import .lib is made, if the list of symbols exported is identical to the previous version, don't update the file. - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:27:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:27:59 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> I think cm3 reacts conservative if an imported library changes because programs may be built standalone. A possible optimization would be to check if the symbols are still the same (as you suggested) and avoid the re-link in case of building shared (but not if building standalone, as the symbols may be the same, but the code has changed). Olaf Quoting Jay : > I see a lot of like: > > == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build > -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] > +++ > --- building in NT386GNU --- > > ignoring ../src/m3overrides > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib > *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo > SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared > -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: > synwr.lib--- shipping from NT386GNU --- > > This is mildly dumb. > I should check as to why m3.lib changed, but an import .lib changing > is rarely legitimate cause for a relink. > As long as no symbols were added or removed, no relink is needed. > Even then, it usually doesn't matter, but harder to tell. > > It's true the import .libs have "hints" as to "ordinals" but I don't > think anyone cares about those. > > Definitely maybe the fix should be that when the import .lib is > made, if the list of symbols exported is identical to the previous > version, don't update the file. > > - Jay > _________________________________________________________________ > Connect and share in new ways with Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 16:32:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:32:16 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> Message-ID: Granted, just given a file path and a timestamp -- don't know if it is an import .lib or not. Either takes more smarts on the consumer, or I think more likely, more smarts on the producer. At least on Windows, the .objs within an import .lib are easily discernable as the special import type and not containing static code. You can actually have hybrid .libs. For example msvcrt.lib contains mostly imports but also static startup code (thus no need for crt0.o or such). Anyway, I think the smarts belong in the producer as that is what would lead to less i/o. I'm starting to need a bug database. :) e.g. cleanup this redundancy: C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.m3(226): tm := localtime(ADR(secs))^ C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; (make ANSI time.h available on Win32 also, if it helps) - Jay > Date: Sat, 23 Feb 2008 16:27:59 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] unnecessary relinks when import libs change> > I think cm3 reacts conservative if an imported library changes> because programs may be built standalone. A possible optimization> would be to check if the symbols are still the same (as you suggested)> and avoid the re-link in case of building shared (but not if building> standalone, as the symbols may be the same, but the code has changed).> > Olaf> > Quoting Jay :> > > I see a lot of like:> >> > == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build > > -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > > 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] > > +++> > --- building in NT386GNU ---> >> > ignoring ../src/m3overrides> > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib > > *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo > > SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared > > -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: > > synwr.lib--- shipping from NT386GNU ---> >> > This is mildly dumb.> > I should check as to why m3.lib changed, but an import .lib changing > > is rarely legitimate cause for a relink.> > As long as no symbols were added or removed, no relink is needed.> > Even then, it usually doesn't matter, but harder to tell.> >> > It's true the import .libs have "hints" as to "ordinals" but I don't > > think anyone cares about those.> >> > Definitely maybe the fix should be that when the import .lib is > > made, if the list of symbols exported is identical to the previous > > version, don't update the file.> >> > - Jay> > _________________________________________________________________> > Connect and share in new ways with Windows Live.> > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 16:38:18 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:38:18 +0000 Subject: [M3devel] response file changes? In-Reply-To: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: Nobody should depend on this strange heuristic-based behavior.. I know that doesn't make it so, but it does possibly legitimize changing it. > as long as their names are unique. Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt. I wrap around from 9 to 0 because Quake can't do math. In practise there's only ever one or two response files per directory, one to make in import .lib and one make a .dll, or just one to link an .exe. C compilation doesn't use response files, but it could if the parameters got long and esp. if there were lots of C files in one directory and batch compile them instead of one at a time.. That's a nice optimization in C-based systems, not a big deal in Modula-3 with so few .c files. Maybe soon I'll rip out my code, and then fix the reliable deletion, and THEN move the directory... - Jay > Date: Sat, 23 Feb 2008 12:04:46 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] response file changes?> > Two short comments:> > o Response files in the target directory should be OK, as long as> their names are unique.> > o The heuristic is built-in to arglist(pfx, array), IIRC; I wouldn't> change that without need. You never know what depends on it, as it> has been there for a long time.> > Olaf> > Quoting Jay :> > > "response files" are files that contain command lines, to > > overcomecommand line length limits. (Why the limits are so small? > > Lame.)> > CM3 has built in support for them.> > I have seen them not be deleted reliably.> > While the deletion should be made more reliable, I propose they be > > writteninto the target directory instead of "temp".> > That is, nearly all writes should be into the target directory.This > > is what is reliably cleaned up when you run "realclean".> >> > I realize there is a tension between putting things that belong > > together together, and reliable deletion, vs. load balancing of I/O. > > "Temp" is sometimes smaller/faster.> > I had already worked around this by wrapping up the response file > > supportin Quake code that moves the file into the target directory > > immediatelyafter creating it. I'll be able to remove that code, and > > live with theunreliably deleted files only when using older tools.> > ?> > Also, the built in support uses a heuristic.For shorter command > > lines, it doesn't use a response file.I found that surprising and a > > bit disappointing.While a more immediately readable log is valuable, > > consistency is too.> > Leave it alone or make it always use a response file?> > The Microsoft C compiler and linker dump the output of any response > > filethey are given, so that gets you a readable log.> >> > I don't care all that much.> > Maybe I'll just look into why the deletion is unreliable, but I > > figure "cleanup" is always unreliable because you might control-c > > the build, or the compiler might crash, etc. There is a "delete on > > close" flag in Windows, but I think it has a problem in that you > > have to keep the file open and if anyone else also opens it, they > > might need file_share_delete, not sure. File_share_delete not being > > supported on Win9x, maybe not much used?> >> > - Jay> > _________________________________________________________________> > Need to know the score, the latest news, or you need your > > Hotmail?-get your "fix".> > http://www.msnmobilefix.com/Default.aspx> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:40:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:40:52 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <20080223162759.kgcobkwakg8gc8ko@mail.elegosoft.com> Message-ID: <20080223164052.lswpp1pc4ksgwwkw@mail.elegosoft.com> Quoting Jay : > Granted, just given a file path and a timestamp -- don't know if it > is an import .lib or not. > Either takes more smarts on the consumer, or I think more likely, > more smarts on the producer. > At least on Windows, the .objs within an import .lib are easily > discernable as the special import type and not containing static > code. You can actually have hybrid .libs. For example msvcrt.lib > contains mostly imports but also static startup code (thus no need > for crt0.o or such). Anyway, I think the smarts belong in the > producer as that is what would lead to less i/o. > > I'm starting to need a bug database. :) We've got one, but it's not externally accessible, and hasn't been used much recently. I've already discussed this topic with others at elego, and we'll setup something during the next weeks (hopefully). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 16:42:53 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:42:53 +0000 Subject: [M3devel] response file changes? In-Reply-To: <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: truncated again... "rip out my code" btw is Quake code in the NT386 config files (and also similar in m3cc and m3gdb on Windows platforms) - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] response file changes?Date: Sat, 23 Feb 2008 15:38:18 +0000 Nobody should depend on this strange heuristic-based behavior..I know that doesn't make it so, but it does possibly legitimize changing it. > as long as their names are unique. Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt.I wrap around from 9 to 0 because Quake can't do math.In practise there's only ever one or two response files per directory, one to make in import .lib and one make a .dll, or just one to link an .exe.C compilation doesn't use response files, but it could if the parameters got long and esp. if there were lots of C files in one directory and batch compile them instead of one at a time.. That's a nice optimization in C-based systems, not a big deal in Modula-3 with so few .c files. Maybe soon I'll rip out my code, and then fix the reliable deletion, and THEN move the directory... - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 16:47:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 15:47:50 +0000 Subject: [M3devel] paths.. In-Reply-To: <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: oky doky it's back to Posix, and pylib.py sniffs cm3.exe to see which it wants...seems to be working pretty ok.. and I still don't need to set those pesky environment variables phew. :) If I can just push out a make-dist output maybe someone will load balance? I still think some things could be improved a bit in terms of knowing or probing host and target behavior. You know, OS_TYPE is target, not host. I cheat and use the OS environment variable, which is Windows_NT on Windows (ignoring 9x). Pushing more stuff into Modula-3 -- "expanding the portable host" -- a la sysutils, definitely helps. - Jay > Date: Sat, 23 Feb 2008 13:39:09 +0100> From: wagner at elegosoft.com> > I'm not really happy with NT386GNU using PathnameWin32.m3. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 16:52:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 16:52:06 +0100 Subject: [M3devel] response file changes? In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223120446.a4wglap68048wcc8@mail.elegosoft.com> Message-ID: <20080223165206.mna5tqyi2o0kokg0@mail.elegosoft.com> Quoting Jay : > Nobody should depend on this strange heuristic-based behavior.. > I know that doesn't make it so, but it does possibly legitimize changing it. OK, probably you're right there. > > as long as their names are unique. > > Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt. > I wrap around from 9 to 0 because Quake can't do math. > In practise there's only ever one or two response files per > directory, one to make in import .lib and one make a .dll, or just > one to link an .exe. We could just add a function to create a unique tmpfile name in a given directory to quake. There's the tempfiles package in m3-libs. Olaf > C compilation doesn't use response files, but it could if the > parameters got long and esp. if there were lots of C files in one > directory and batch compile them instead of one at a time.. That's a > nice optimization in C-based systems, not a big deal in Modula-3 > with so few .c files. > > Maybe soon I'll rip out my code, and then fix the reliable deletion, > and THEN move the directory... > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Feb 23 17:24:29 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 23 Feb 2008 11:24:29 -0500 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Why @M3novm? That should no longer be needed. On Feb 23, 2008, at 10:04 AM, Jay wrote: > I see a lot of like: > > == package C:\\dev2\\cm3.2\m3-obliq\synloc == > +++ ['cm3.exe -build -keep -DROOT=/C/dev2/cm3.2 - > DCM3_VERSION_TEXT=d5.6.0 -DCM3 > _VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > 'cm3.exe -ship -k > eep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 - > DCM3_VERSION_NUMBER=050600 - > DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ > > --- building in NT386GNU --- > > ignoring ../src/m3overrides > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving > synwr.lib *** This line **** > mklib -out:synwr.lib SynWr.io SynWr.mo SynLocation.io > SynLocation.mo 2>&1 > sy > nwr.lst > gcc -shared -Wl, at _m3responsefile1.txt 2>&1 > synwr.lst > Creating library file: synwr.lib > --- shipping from NT386GNU --- > > This is mildly dumb. > I should check as to why m3.lib changed, but an import .lib > changing is rarely legitimate cause for a relink. > As long as no symbols were added or removed, no relink is needed. > Even then, it usually doesn't matter, but harder to tell. > > It's true the import .libs have "hints" as to "ordinals" but I > don't think anyone cares about those. > > Definitely maybe the fix should be that when the import .lib is > made, if the list of symbols exported is identical to the previous > version, don't update the file. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Sat Feb 23 17:42:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 16:42:27 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: For bootstrapping from older tools. I have one set of configuration files (the checked in ones) that don't require any editing and do whatever runtime probing is needed (such as for the gc wrap flags on PPC_LINUX). I have a consistent crash building with older tools that I wasn't able to debug or otherwise workaround. On Windows I occasionally start over from 5.1.8. 5.1.3 would work but sysutils can't be compiled against its runtime. I was going to see about booting from 4.1 or 3.6 but I figure no go for the same reason. I've asked but no answer as to what people think about buildability with older tools. Probably it's not a valuable battle, otherwise progress is blocked. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] unnecessary relinks when import libs change> Date: Sat, 23 Feb 2008 11:24:29 -0500> To: jayk123 at hotmail.com> > Why @M3novm? That should no longer be needed. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sat Feb 23 18:31:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 23 Feb 2008 11:31:36 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> Message-ID: <47C05878.1050101@wichita.edu> I guess I misunderstood. I had the idea from the quoted text below that MAC OS X needed a mixture of lazy and strict alignment. If every platform uses the same alignment rules for all types of all programs on the platform, then the alignment rule property can just be made an additional field of the RTPacking.T. This is much easier to do without compatibility problems, because this value is encoded in bits in a 32-bit word in pickle headers, with unused bits that are now ignored. The alignment strategy could just be in another bit. From a post on 2-11: --------------------------------------------------------------------------------------------------------- That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for historical reasons. All other structures should use normal alignment to be compatible with C and Unix interfaces. The alignment change was implemented to be supported only in packed structures as a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly restrictive alignment rules in packed structures. On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > It sounds like all that Mac OS X needs is for _all_ types in an entire > program to use the liberal packing rules. Have I understood correctly? > I would have no grief over that. --------------------------------------------------------------------------------------------------------- Darko wrote: > The alignment rules are particular to a platform, not a type (at least > after we get rid of the pragma), so is there no field where we can > encode some information about the platform in the pickle header or > something? Where is endian stored? > > -- ------------------------------------------------------------- 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 Sat Feb 23 18:36:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 17:36:12 +0000 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: scripts\pylib.py: ## workaround crash when booting from 5.1.3 that is# difficult to debug -- crashes earlier in debugger# without this switch, no repro with this switch## This has no effect with current tools/libraries.#DEFS += " @M3novm" From: jayk123 at hotmail.com.. > From: hosking at cs.purdue.edu> > Why @M3novm? That should no longer be needed. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 18:40:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 18:40:25 +0100 Subject: [M3devel] unnecessary relinks when import libs change In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: <20080223184025.arvp8z5lc8ww4wgg@mail.elegosoft.com> Quoting Jay : > On Windows I occasionally start over from 5.1.8. > 5.1.3 would work but sysutils can't be compiled against its runtime. > I was going to see about booting from 4.1 or 3.6 but I figure no go > for the same reason. That's probably because modules have been added to m3core and libm3. > I've asked but no answer as to what people think about buildability > with older tools. > Probably it's not a valuable battle, otherwise progress is blocked. I don't think it's worth the efforts to try to remain boot-compatible with all older versions of M3. We can still use cross-compilation if there's dire need. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 19:11:29 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 18:11:29 +0000 Subject: [M3devel] NT386GNU distribution available (Cygwin this time) In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: birch: /var/www/modula3.elegosoft.com/cm3/uploaded-archives Now has cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 It doesn't appear on http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html This is a "Cygwin" based release.(From now on, the older MinGWin-based target will probably be called NT386MINGNU,though there are archives out there named "NT386GNU" that are MinGWin-based). It extracts like: tar xfj cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 cm3-min-POSIX-NT386GNU-d5.6.0/bin/cm3.cfg cm3-min-POSIX-NT386GNU-d5.6.0/bin/cm3.exe ... and then you rename or copy to \cm3 or /usr/local/cm3 or whatever. If you are using scripts\python\*, then set CM3_OSTYPE=POSIX and everything else should be figured out. TBD: If cl.exe/link.exe aren't on the path, then setting CM3_OSTYPE ought not be necessary. Sniffing uname and gcc -v should suffice. But that isn't the case yet. This distribution also includes the config files for NT386 and NT386MINGNU and should be able to target them. You can edit the one line cm3.cfg. I didn't test that aspect. (Really, if you build the cross gcc/ld tools, any cm3 can target any target.) A reasonable way to go is thus: tar xvj cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 rmdir /q/s \cm3 xcopy /fivery cm3-min-POSIX-NT386GNU-d5.6.0 \cm3 set PATH=c:\cm3\bin;c:\cygwin\bin;%PATH% cd \dev2\cm3.2\scripts\python upgrade do-cm3-all realclean do-cm3-std buildship It will error eventually, but after building a lot. Anyone game to try it and report back? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 23 19:26:55 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 18:26:55 +0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47C05878.1050101@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> Message-ID: kind of obnoxious of me here sorry: I am not volunteering to do any work here. :) I propose that declaration that interface with C be declared PACKED (if that even exists) or BITS n FOR (I know that exists; it was pointed out to me and I have been using it). I would like to be able to say BYTES n FOR, but ok, I say BITS n * 8 FOR. I propose there be a command line switch, or interface/module-level pragma that issues warnings or errors for any apparent need to insert any padding. I propose that any padding for alignment that is needed to interface with existing C code be explicitly inserted. I propose that when you say BITS n FOR, you be able to get a warning/error if the size isn't exactly right. I know it is already an error today if the size is too small, but I assume the compiler will grow the type to fit if it is "too big" and I'd rather not have that. On the other hand, while I have been using BITS n FOR, I make up an arbitrary type. That is, I say: Foo = BITS exact FOR RECORD blah blah pad : BITS exact FOR arbitrary small type such as [0..0] END; While I don't want the compiler to expand Foo up to exact, I don't care about the [0..0] thing. I guess in the interest of being less lazy and coming up with a simpler feature set, I am willing to be more precise in the padding. Or maybe a new type can be invented BITS exact for Padding. And maybe you can tack on ":= 0" to it, no matter the size. (Notice how in the socket code, the type of the padding can't be changed willy nilly because there is code to zero initialize it; seems a little bit lame to me.) I would probably volunteer to do some of the header repair here. Alignment issues bother me and I think we might be in a position to solve them once and for all for Modula-3, in a reasonable simple, clear, reliable, multi-target way. Part of this proposal would need to distinguish at least three scenarios: exact layout for interfacing with existing C stable layout for interface with self -- declare some new type in Modula-3 that I can pickle on multiple platforms but which Modula-3 can determine the layout of; padding can be inserted here but it must be the same across various time/space/configuration don't care layout for data that will only ever be in memory and shared amongst code built by the same basic compiler with the same declarations; padding can be inserted here and vary from build to build or such another case: exact layout for interfacing with existing Modula-3/pickles. Or maybe simply pickles need persisted metadata about the various fields, offsets, sizes? I have never used pickles or looked at the code... - Jay > Date: Sat, 23 Feb 2008 11:31:36 -0600> From: rodney.bates at wichita.edu> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] <*LAZYALIGN*>> > I guess I misunderstood. I had the idea from the quoted text below that MAC OS X needed a mixture> of lazy and strict alignment. If every platform uses the same alignment rules for all types of all> programs on the platform, then the alignment rule property can just be made an additional field of> the RTPacking.T.> > This is much easier to do without compatibility problems, because this value is encoded in bits> in a 32-bit word in pickle headers, with unused bits that are now ignored. The alignment strategy> could just be in another bit.> > > From a post on 2-11:> ---------------------------------------------------------------------------------------------------------> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for > historical reasons. All other structures should use normal alignment to be compatible with C and > Unix interfaces. The alignment change was implemented to be supported only in packed structures as > a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly > restrictive alignment rules in packed structures.> > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:> > > It sounds like all that Mac OS X needs is for _all_ types in an entire> > program to use the liberal packing rules. Have I understood correctly?> > I would have no grief over that.> ---------------------------------------------------------------------------------------------------------> > Darko wrote:> > The alignment rules are particular to a platform, not a type (at least > > after we get rid of the pragma), so is there no field where we can > > encode some information about the platform in the pickle header or > > something? Where is endian stored?> > > > > -- > -------------------------------------------------------------> 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 _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 23 20:29:11 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 20:29:11 +0100 Subject: [M3devel] NT386GNU distribution available (Cygwin this time) In-Reply-To: References: <1CB59EBE-DCD8-4254-B342-6AF39EFC6AB5@darko.org> <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <42777285-E1FD-4000-BC83-E25011A851A3@cs.purdue.edu> Message-ID: <20080223202911.ca9eq2e74kwcgwck@mail.elegosoft.com> Quoting Jay : > birch: /var/www/modula3.elegosoft.com/cm3/uploaded-archives > Now has cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2 > It doesn't appear on > http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html This is because it is no `daily snapshot'. Daily snapshots are built by the daily regression runs. Uploaded files appear on http://www.opencm3.net/ --> Installation --> Uploaded Archives: http://www.opencm3.net/uploaded-archives/index.html :-) You could also add the description from your email as one of cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2.{README,txt,html} and an appropriate link will be shown on the page. The index is updated every 30 minutes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 21:03:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 23 Feb 2008 21:03:23 +0100 Subject: [M3devel] CM3 Tinderbox Display Message-ID: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> I've made some changes to the tinderbox display: 1. The last 48 hours are displayed by default now. 2. I switched the display mode from build-event time to event time. In build-event time (which is more compact), current build records were often not displayed for unknown reasons. Someone with more perl knowlege must look into this (Ronny?) With event time granularity, we get an entry for every CVS checkin, too. 3. I changed the VC switch in DBImpl from 'TinderDB::VC_Bonsai' to 'TinderDB::VC_CVS'. This seems to give us some entries in the Guilty column. The previous build time in the pop-ups is still broken, so that the Bonsai queries for `check-ins since last build' don't work. I also disabled some suspicious db deletes in the perl code, which may have been responsible for the loss of data we've seen (I386_DARWIN, for example). BTW, is there a Perl guru on this list who could fix things faster than me? (Our administrator cannot spend too much time for this stuff, and Kaspar seems still to be bound by his studies.) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 23 21:28:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 23 Feb 2008 20:28:32 +0000 Subject: [M3devel] CM3 Tinderbox Display In-Reply-To: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: I'm so-so with Perl..but way out of context, and not done any database stuff in any domain...have started trying to run the tinderbox and regression tests today..some luck running the tests, not much with tinderbox yet..I got it to do the cvs checkout, and I extracted my archive where it wanted it..got as far as: $ ( . defs.sh ; test_build_core_rel )hostname: invalid option -- sTry `hostname --help' for more information.TESTHOSTNAME=WS=/home/Jay/work/cm3-ws/-2008-02-23-20-23-57LASTREL=5.4.0INSTROOT_REL=/home/Jay/work/cm3-inst//rel-5.4.0INSTROOT_POK=/home/Jay/work/cm3-inst//prev-okINSTROOT_LOK=/home/Jay/work/cm3-inst//last-okINSTROOT_CUR=/home/Jay/work/cm3-inst//currentCM3_OSTYPE=WIN32CM3_TARGET=NT386BINDISTMIN=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2CM3CVSSERVER=jkrell at m3.elegosoft.comCM3CVSROOT=:ext:jkrell at m3.elegosoft.com:/usr/cvsBINDISTMIN_NAME=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2BINDISTMIN=cm3-min-POSIX-NT386GNU-d5.6.0.tar.bz2testing ssh jkrell at m3.elegosoft.com..ssh jkrell at m3.elegosoft.com ok === 2008-02-23 20:24:01 build cm3 core in /home/Jay/work/cm3-ws/-2008-02-23-20-23-57 with last release /home/Jay/work/cm3-inst//rel-5.4.0Critical Mass Modula-3 version d5.6.0 last updated: 2008-01-31 compiled: 2008-02-23 17:41:32 configuration: /home/Jay/work/cm3-inst//current/bin/cm3.cfg bash: cd: /home/Jay/work/cm3-ws/-2008-02-23-20-23-57/cm3: No such file or directorygotta run for a while. - Jay > Date: Sat, 23 Feb 2008 21:03:23 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> CC: m3-support at elegosoft.com; tobermueller at elegosoft.com> Subject: [M3devel] CM3 Tinderbox Display> > I've made some changes to the tinderbox display:> > 1. The last 48 hours are displayed by default now.> > 2. I switched the display mode from build-event time to> event time. In build-event time (which is more compact),> current build records were often not displayed for unknown> reasons. Someone with more perl knowlege must look into this> (Ronny?) With event time granularity, we get an entry for> every CVS checkin, too.> > 3. I changed the VC switch in DBImpl from 'TinderDB::VC_Bonsai' to> 'TinderDB::VC_CVS'. This seems to give us some entries in the> Guilty column.> > The previous build time in the pop-ups is still broken, so that> the Bonsai queries for `check-ins since last build' don't work.> > I also disabled some suspicious db deletes in the perl code,> which may have been responsible for the loss of data we've seen> (I386_DARWIN, for example).> > BTW, is there a Perl guru on this list who could fix things faster> than me? (Our administrator cannot spend too much time for this stuff,> and Kaspar seems still to be bound by his studies.)> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 24 01:01:05 2008 From: darko at darko.org (Darko) Date: Sun, 24 Feb 2008 11:01:05 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47C05878.1050101@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> Message-ID: <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> What I meant to say below is that unpacked structures are aligned according to the normal rules under Darwin. The problem is that the packed alignment rules without the change are too restrictive. On 24/02/2008, at 4:31 AM, Rodney M. Bates wrote: > I guess I misunderstood. I had the idea from the quoted text below > that MAC OS X needed a mixture > of lazy and strict alignment. If every platform uses the same > alignment rules for all types of all > programs on the platform, then the alignment rule property can just > be made an additional field of > the RTPacking.T. > > This is much easier to do without compatibility problems, because > this value is encoded in bits > in a 32-bit word in pickle headers, with unused bits that are now > ignored. The alignment strategy > could just be in another bit. > > > From a post on 2-11: > --------------------------------------------------------------------------------------------------------- > That's not quite right. Certain Mac API structures need to be > aligned to Motorola 68K alignment for historical reasons. All other > structures should use normal alignment to be compatible with C and > Unix interfaces. The alignment change was implemented to be > supported only in packed structures as a natural and intuitive way > to "force" alignment. You could view it as a bug fix to overly > restrictive alignment rules in packed structures. > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > > > It sounds like all that Mac OS X needs is for _all_ types in an > entire > > program to use the liberal packing rules. Have I understood > correctly? > > I would have no grief over that. > --------------------------------------------------------------------------------------------------------- > > Darko wrote: >> The alignment rules are particular to a platform, not a type (at >> least after we get rid of the pragma), so is there no field where >> we can encode some information about the platform in the pickle >> header or something? Where is endian stored? > -- > ------------------------------------------------------------- > 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 Feb 24 01:22:29 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 00:22:29 +0000 Subject: [M3devel] exposing both path name types? In-Reply-To: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: What is the idiom for this: Currently: There is Pathname.i3. PathnamePosix EXPORTS Pathname PathnameWin32 EXPORTS Pathname You can only have one in a link. It would seem possibly useful to have: Pathname.i3 unchanged PathnamePosix.i3 identical to Pathname.i3 (some what to avoid the duplication?) PathnameWin32.i3 identical to Pathname.i3 (ditto) On Posix targets: PathnameWin32.m3 exports just PathnameWin32 PathnamePosix exports both PathnamePosix and Pathname On Windows targets: PathnamePosix exports just PathnamePosix PathnameWin32 exports both PathnameWin32 and Pathname That is Pathname.Foo resolves statically at compile time to the target-specific library. PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. These modules each import nothing, except Text. They do all their string manipulation themselves. Olaf's recent Quake extensions document but don't implement pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> text As long as pn is a fullpath, these are easy, I just wrote up prototypes, haven't compiled them. I think these functions might suggest doing what I'm asking about as well, maybe. Or maybe you'd just convert and then never pick back apart. I have sleazed by for now by using subst_text / to \ and setting up NTFS junctions. In this way, I can cross build NT386 <=> NT386GNU either host, either target. Had I not done anything, the linker interprets /cygdrive/c/foo/bar.lib as a command switch and says it doesn't understand it. Not a big deal, but I think there might be some easy progress here. This is not just about Pathname. It is also about File. Even though NT386GNU File is FilePosix, it would be useful to allow the serial package to use FileWin32 instead. But FilePosix and FileWin32 both reveal the same types. It'd be nice if they could expose FilePosix.T and FileWin32.T and then only one of them reveal File.T = FilePosix.T or File.T = FileWin32.T, something like that. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 24 01:34:13 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 00:34:13 +0000 Subject: [M3devel] exposing both path name types? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: Oh I think I see some of how to do this. Olaf's path stuff is actually implemented, maybe just not exposed, and perhaps incomplete, but it demonstrates a "trick" of Modula-3. You can do this: INTERFACE I; PROCEDURE F1(); PROCEDURE F2(); END I; MODULE A EXPORTS I; PRODEDURE F1() = ... END F1; MODULE B EXPORTS I; PRODEDURE F2() = ... END F2; The implementation of interface can be distributed among multiple modules. To export an interface just means to implement some or all of it. Usually but not necessarily all. (I wonder what if you implement none of it?) That helps much. It doesn't provide a complete idiom I think for what I ask, but it is a start. I suspect generics help here. But I'm still not sure what the entire answer is. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sun, 24 Feb 2008 00:22:29 +0000Subject: [M3devel] exposing both path name types? What is the idiom for this: Currently:There is Pathname.i3.PathnamePosix EXPORTS PathnamePathnameWin32 EXPORTS PathnameYou can only have one in a link. It would seem possibly useful to have:Pathname.i3 unchangedPathnamePosix.i3 identical to Pathname.i3 (some what to avoid the duplication?)PathnameWin32.i3 identical to Pathname.i3 (ditto) On Posix targets: PathnameWin32.m3 exports just PathnameWin32 PathnamePosix exports both PathnamePosix and Pathname On Windows targets: PathnamePosix exports just PathnamePosix PathnameWin32 exports both PathnameWin32 and Pathname That is Pathname.Foo resolves statically at compile time to the target-specific library.PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. These modules each import nothing, except Text. They do all their string manipulation themselves. Olaf's recent Quake extensions document but don't implement pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> textAs long as pn is a fullpath, these are easy, I just wrote up prototypes, haven't compiled them. I think these functions might suggest doing what I'm asking about as well, maybe.Or maybe you'd just convert and then never pick back apart. I have sleazed by for now by using subst_text / to \ and setting up NTFS junctions.In this way, I can cross build NT386 <=> NT386GNU either host, either target.Had I not done anything, the linker interprets /cygdrive/c/foo/bar.lib as a command switch and says it doesn't understand it.Not a big deal, but I think there might be some easy progress here. This is not just about Pathname. It is also about File.Even though NT386GNU File is FilePosix, it would be useful to allow the serial package to use FileWin32 instead.But FilePosix and FileWin32 both reveal the same types.It'd be nice if they could expose FilePosix.T and FileWin32.T and then only one of them reveal File.T = FilePosix.T or File.T = FileWin32.T, something like that. - Jay Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 24 01:59:03 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 24 Feb 2008 01:59:03 +0100 Subject: [M3devel] Do I remember well... Message-ID: <1203814743.7865.25.camel@hias.m3w.org> Once, there was a talk about (original?) CM3 making checked runtime errors behave like exceptions? -- Dragi?a Duri? From wagner at elegosoft.com Sun Feb 24 02:19:34 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 02:19:34 +0100 Subject: [M3devel] Do I remember well... In-Reply-To: <1203814743.7865.25.camel@hias.m3w.org> References: <1203814743.7865.25.camel@hias.m3w.org> Message-ID: <20080224021934.ll0vw5k2swoooccs@mail.elegosoft.com> Quoting Dragi?a Duri? : > Once, there was a talk about (original?) CM3 making checked runtime > errors behave like exceptions? Yes. See http://www.opencm3.net/about-cm3.html: o <*IMPLICIT*> exceptions (changes language semantics) o checked runtime errors are mapped to the implicit exception RuntimeError.E I don't think anything has changed in this area. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 24 12:03:34 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 11:03:34 +0000 Subject: [M3devel] another nt/posix target? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: This is really getting a head of things, but I think maybe there should be a target for "Services for Unix". Probably called X86_INTERIX or something? Or X86_INTERIX_GCC and X86_INTERIX_MSVC? Or X86_SFU_GNU, X86_SFU_MS? Or simply X86_NTX? I think the different tools might not matter -- might be just "cc" vs. "gcc" and the same runtime, same setjmp buffer. It looks like you have a choice of compilers. It looks like a pretty good system from a Posix point of view. I have to try it out more. And maybe stay on other areas for now. Pthreads looks definitely viable here, so start with the Cygwin "minimized" "headers" (.i3) files, correct them, add back pthreads (and dependent signal stuf..) I know it's too late, but I guess naming scheme should have included "OS_TYPE". X86_WIN32_MSVC X86_WIN32_BLAND (Borland) X86_WIN32_DMARS (Digital Mars) X86_WIN32_WAT (Open Watcom) X86_WIN32_GCC (MinGWin) or maybe clearer X86_WIN32_MINGWIN X86_POSIX_GCC (Cygwin) or maybe clearer X86_POSIX_CYGWIN X86_POSIX_SFU or X86_POSIX_INTERIX or X86_POSIX_INTERIX_GCC or X86_POSIX_INTERIX_MSVC etc. Then, to the extent that these are all the same, it seems like I did a good thing separating "target" from "configuration"? Or again, compiler is a configuration thing, runtime due to jmpbuf size is something the compiler needs to know about, and processor actually the compiler hardly cares about -- it has to know 32bit vs. 64bit, and then just to call cm3cg usually.. :) Anyway, let's retable the general issue and just, PERHAPS, discuss Interix/SFU. A target/config name is probably all, X86_INTERIX or X86_SFU, or X86_MSWINX or X86_WINPOSIX or X86_POSIX_MS or X86_POSIX_NT X86_NTPOSIX something.. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 24 16:42:02 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 15:42:02 +0000 Subject: [M3devel] duplicate link info for stuff that has been deleted? In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: do-cm3-std buildship == package C:\dev2\cm3.2\m3-www\http == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5. 6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSI ON_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++ --- building in NT386GNU --- ignoring ../src/m3overrides Fatal Error: duplicate link info: FastLex.i3 I know I know, not a big deal, easy workaround: => do-pkg http realclean But is this something the builder is supposed to handle? I'm too lazy to read the code right now... ps: here's a hueristic: if two libraries have identical code, it might be a good candidate for libm3? :) (I'm all for kitchen sink libraries, that way I can just depend on one and not worry about it. I'm a heretic though, I know.) - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 24 16:53:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:53:16 +0100 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: <20080224165316.xibqnumt6sg0s8kk@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Jay : > >> Oh darn, inevitably that is not my final answer.. >> more like attached.. > > Jay, > > the files seem to work OK on my FreeBSD system. But the tinderbox > tests on birch and new have failed, in spite of my CVS revert; > so please don't commit anything until I have found out what is wrong. > It may take some time, because I'm expecting guests soon and won't > be able to do much until tomorrow evening. OK, I think I've found it, two different reasons for the failures. On Linux we need to use libiodbc instead of libodbc as on FreeBSD, and on new.elego.de the changes just hadn't been cvsupped. On Darwin the tests succeeded again, though, so my change had an effect. Jay, you can commit your latest cm3 versions now, and I'll try to correct the odbc stuff. We'll know if it works tomorrow morning then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 24 16:58:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 24 Feb 2008 15:58:20 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: Ok, I see: http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-FreeBSD4.html#tr_m3-db-odbcIt really must be: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Path.m3.diff?r1=1.14;r2=1.15 The error is unable to open "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../odbc/FreeBSD4/.M3EXPORTS" but it should be trying to open: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../../../odbc/FreeBSD4/.M3EXPORTS" or, fixed up: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/FreeBSD4/.M3EXPORTS" My change is making it remove two instances of .. at once or something like that. I still am not reading it fully, but this must be it. Overrides are often/usually "built down" from ROOT, but in this case they are "built up". Anyway I'm off to debug: == package C:\dev2\cm3.2\m3-obliq\obliqrt == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++--- building in NT386GNU --- ignoring ../src/m3overrides /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB/cygdrive/C/cm3/bin/shobjcodegen: Processing ObValue.ReplObjStd"/cygdrive/C/cm3/pkg/sharedobj/src/sharedobj.tmpl", line 49: quake runtime error: exit 35584: /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB and I have guests coming soon too. :) - Jay > Date: Sun, 24 Feb 2008 16:32:05 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: Revert cm3 to version 6 days ago> > Quoting Jay :> > > Oh darn, inevitably that is not my final answer..> > more like attached..> > Jay,> > the files seem to work OK on my FreeBSD system. But the tinderbox> tests on birch and new have failed, in spite of my CVS revert;> so please don't commit anything until I have found out what is wrong.> It may take some time, because I'm expecting guests soon and won't> be able to do much until tomorrow evening.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000> >> >> > Olaf can you try the attached? Thanks, - Jay> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Feb 24 22:54:34 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 Feb 2008 13:54:34 -0800 Subject: [M3devel] paths.. In-Reply-To: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> Message-ID: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Olaf, you're right: People who use Cygwin are used to dealing with all kinds of oddities. I am here reproducing "README.CYGWIN" from the top level of my M3 project (note the stuff after "IMPORTANT SECTION FOLLOWS"). In my opinion (and I think of everyone else who appears to use NT386GNU and also post to this mailing list) the point of Cygwin is to work as a crutch for Unix people who really, really don't want to use Windows, but are forced for some (probably economic) reason to do so... We want as much Unix and as little Windows as possible, and we're willing to jump through all sorts of hoops to get our way.... Mika # # $Id: README.CYGWIN,v 1.3 2007/07/28 23:43:50 mika Exp $ # ===== Basic instructions ===== If you are just building, not maintaining, just export CYGWIN=1 before compiling. If you are not building as user "mika", you will have to make some changes to Make.defs (please look at that file). ===== From-Scratch Installation ===== Installing this system on Cygwin can be a little tricky. So far, it's only been tested with the old PM3 distribution from Klagenfurt (?). This PM3 comes on 44 "floppies" and is installed in accordance with the instructions (in German) located at http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html Having installed the PM3 distribution, building small, self-contained Modula-3 programs should be no problem. However, it is different with this software distribution. During the build process, tools are built that are used later on in the same build process. For various reasons, m3 "overrides" don't seem to work right on Cygwin/PM3-Klagenfurt, so we build a "distribution" system and m3ship everything. ===== IMPORTANT SECTION FOLLOWS ===== The main thing that has to be done to simplify the work of the build system is to make sure that DOS and Cygwin directory paths match AS MUCH AS POSSIBLE. This is difficult, because by default, Cygwin has a different view of the "root" of the filesystem from the standard DOS view. Running under Cygwin, the Klagenfurt system unfortunately sometimes takes the DOS view and sometimes takes the Cygwin view. The situation is further complicated by the fact that Windows doesn't have proper symbolic links. The saving grace is that Cygwin DOES have proper symbolic links. The solution is therefore to make the directory structure that is desired under DOS and then link to it from within the Cygwin hierarchy. Therefore: Move the users' home directories to C:\home and make the links as follows: Cygwin link DOS equivalent /home -> /cygdrive/c/home C:\cygwin\home -> C:\home etc. The filenames are still occasionally polluted by DOS things like backslashes and drive letters. The scripts in cygwinhacks should take care of most of the remaining problems of this sort. I am not sure this system can be made to work if your system disk is called anything other than C:. Best not to try. (end of README.CYGWIN) Olaf Wagner writes: >Jay, > >I'm not really happy with NT386GNU using PathnameWin32.m3. >In my opininion it should just use the POSIX code, whatever problems >people will have with their installation roots. (These can be avoided >by using the /cygdrive/... equivalents.) >Why don't we just assume that by deafult CM3 is installed in >/usr/local/cm3 as for all other targets (except NT386, of course)? > >One thing that immediately comes to mind is that all paths output >by CM3 programs will contain \ instead of / then and thus be >unusable for simple copy-and-paste, as \ is the escape character >in all POSIX command line tools. So this seems kind of incompatible >to me. > >Olaf > >Quoting Jay : > >> I could be wrong about many things here: >> >> Cygwin fopen and I presume open accepts all of: >> c:\foo, c:/foo, /foo, \foo >> >> /foo and \foo probably have a different meaning between Cygwin and Win32. >> In Win32, /foo and \foo are, well, \foo, on the current drive. >> In Cygwin, /foo is probably /foo at the Cygwin root. >> I'd kind of like to be wrong here, about \foo having different >> meanings between them, since it a common form for me. >> >> Cygwin does not accept c:foo. >> In Win32 c:foo is foo in the current working directory of the C: drive. >> I don't think c:foo is used often, but it does have a meaning. >> >> Now, as well, cm3 has its own Path module, M3Path, but I realized >> tonight it also uses libm3's Pathname module a fair amount. In >> particular, I was having errors "shipping". >> >> This throws a big monkey wrench into where I was going. >> So now, after a bunch of going back and forth on various uncommited >> changes, I have now switched (and commited) NT386GNU to use >> PathnameWin32.m3. To some extent, this strikes at the core of "what >> is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". >> However, remember that Cygwin does appear to accept Win32 paths. >> So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that >> Win32 accepts /foo, is it Posix?) As well, this target still uses >> cygwin1.dll for its all its odd behaviors. It still uses >> open/read/write (again, remember that msvcrt.dll DOES expose these >> SAME functions..I still contend that Win32 is close enough to Posix >> to satisfy almost everyone..and then X Windows can be dealt with >> separately maybe, or Trestle/Win32 fixed). >> >> I have some more testing to do but I think this switch will fly, and >> various other options can go away. >> And I can undo the small amount I had commited. >> I think I'll just send my m3path.m3 diff around and then delete it. >> >> I ended up with a set based approach where host and target have a >> set of dir separaters, volume separaters, and separators (union of >> previous two). These are TINY sets, containing a maximum of three >> characters each, and '/' is always a member of two of them. So a set >> is kind of overkill. But it works out pretty ok. >> >> - Jay >> _________________________________________________________________ >> Need to know the score, the latest news, or you need your >> Hotmail??-get your "fix". >> http://www.msnmobilefix.com/Default.aspx > > > >-- >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Sun Feb 24 20:59:30 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 24 Feb 2008 13:59:30 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> <25987.165.228.199.218.1203385442.squirrel@webmail.darko.org> <621419BF-3436-4A92-8EF5-326829D45C37@cs.purdue.edu> <0098608F-8AAF-4FF7-8FFA-23E5C4E58030@darko.org> <47BEEBB3.6000800@wichita.edu> <47BF436D.9080608@wichita.edu> <071811CE-F30F-4D81-8F4D-43E854BD9441@darko.org> <47BF9C0A.8000804@wichita.edu> <47C05878.1050101@wichita.edu> <25F2DF1C-B223-4D9F-A575-4CC0EA6FA985@darko.org> Message-ID: <47C1CCA2.8060503@wichita.edu> Ahh, I get it. This will be much simpler than I thought. Darko wrote: > What I meant to say below is that unpacked structures are aligned > according to the normal rules under Darwin. The problem is that the > packed alignment rules without the change are too restrictive. > > On 24/02/2008, at 4:31 AM, Rodney M. Bates wrote: > >> I guess I misunderstood. I had the idea from the quoted text below >> that MAC OS X needed a mixture >> of lazy and strict alignment. If every platform uses the same >> alignment rules for all types of all >> programs on the platform, then the alignment rule property can just >> be made an additional field of >> the RTPacking.T. >> >> This is much easier to do without compatibility problems, because >> this value is encoded in bits >> in a 32-bit word in pickle headers, with unused bits that are now >> ignored. The alignment strategy >> could just be in another bit. >> >> >> From a post on 2-11: >> --------------------------------------------------------------------------------------------------------- >> >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All other >> structures should use normal alignment to be compatible with C and >> Unix interfaces. The alignment change was implemented to be >> supported only in packed structures as a natural and intuitive way >> to "force" alignment. You could view it as a bug fix to overly >> restrictive alignment rules in packed structures. >> >> >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >> >> > It sounds like all that Mac OS X needs is for _all_ types in an entire >> > program to use the liberal packing rules. Have I understood >> correctly? >> > I would have no grief over that. >> --------------------------------------------------------------------------------------------------------- >> >> >> Darko wrote: >> >>> The alignment rules are particular to a platform, not a type (at >>> least after we get rid of the pragma), so is there no field where >>> we can encode some information about the platform in the pickle >>> header or something? Where is endian stored? >> >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 mika at async.caltech.edu Sun Feb 24 23:24:30 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 24 Feb 2008 14:24:30 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> Message-ID: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Surely the SPIN people had to do that? I've wanted it a few times, too. Mika =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Once, there was a talk about (original?) CM3 making checked runtime >errors behave like exceptions? >-- >Dragi??a Duri?? From jayk123 at hotmail.com Mon Feb 25 09:13:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:13:50 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: Here is an unnecessarily complete explanation: The problem was Given "a../..", M3Path.FixPath wasn't doing anything. I wanted to fix that. It would collapse "a/.." or ".a/.." or "a./.." correctly, but not "a../.." I know people will disagree as to what is "correct" due to symlinks, but this was/is the behavior. Given input like "../.." it should also leave that alone, because "there is nowhere for it to go". In fixing "a../.." to collapse to nothing or ".", I also broke leaving "../.." alone. I thought the check for "is the element prior to ".." also ".."?" wasn't needed, since they get removed, left to right, and the scan is restarted for every change, but they aren't removed if "there is nowhere to go", so the check is valid. But the check wasn't right. It didn't check for a ".." element, it checked for an element ending in "..". NOW it should be treating them both correctly, as well as not indexing out of bounds for other input as it was doing. I added a check that the previous element is of length 2, and "ends" "..". Yes, I realize that elements ending in ".." but not equal to ".." are rare and not particularly interesting. Windows even has trouble with them: C:\>mkdir a.. C:\>dir a* 02/25/2008 12:11 AM a Huh? C:\>mkdir \\?\c:\a.. C:\>dir a* 02/25/2008 12:11 AM a 02/25/2008 12:12 AM a.. C:\>rmdir a.. C:\>dir a* 02/25/2008 12:12 AM a.. Huh? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.comDate: Sun, 24 Feb 2008 15:58:20 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] Revert cm3 to version 6 days ago Ok, I see:http://modula3.elegosoft.com/cm3/logs/cm3-pkg-report-FreeBSD4.html#tr_m3-db-odbcIt really must be:http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3Path.m3.diff?r1=1.14;r2=1.15 The error is unable to open "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../odbc/FreeBSD4/.M3EXPORTS" but it should be trying to open: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/test/src/../../../odbc/FreeBSD4/.M3EXPORTS" or, fixed up: "/pub/users/m3/work/cm3-ws/new.elego.de-2008-02-24-13-13-31/cm3/m3-db/odbc/FreeBSD4/.M3EXPORTS" My change is making it remove two instances of .. at once or something like that.I still am not reading it fully, but this must be it. Overrides are often/usually "built down" from ROOT, but in this case they are "built up". Anyway I'm off to debug:== package C:\dev2\cm3.2\m3-obliq\obliqrt == +++ ['cm3.exe -build -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', 'cm3.exe -ship -keep -DROOT=/cygdrive/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] +++--- building in NT386GNU ---ignoring ../src/m3overrides/cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB/cygdrive/C/cm3/bin/shobjcodegen: Processing ObValue.ReplObjStd"/cygdrive/C/cm3/pkg/sharedobj/src/sharedobj.tmpl", line 49: quake runtime error: exit 35584: /cygdrive/C/cm3/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB and I have guests coming soon too. :) - Jay > Date: Sun, 24 Feb 2008 16:32:05 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: Revert cm3 to version 6 days ago> > Quoting Jay :> > > Oh darn, inevitably that is not my final answer..> > more like attached..> > Jay,> > the files seem to work OK on my FreeBSD system. But the tinderbox> tests on birch and new have failed, in spite of my CVS revert;> so please don't commit anything until I have found out what is wrong.> It may take some time, because I'm expecting guests soon and won't> be able to do much until tomorrow evening.> > Olaf> > > - Jay> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000> >> >> > Olaf can you try the attached? Thanks, - Jay> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:31:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:31:47 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: It is easier than today I think, and might be made even easier. Unix doesn't have to be as hard as possible, though I guess I'm a heretic on this point too. Unix seems to be all about making things much harder than necessary. I am using a workaround for at least some scenarios. In particular I have some NTFS junctions and some Cygwin symlinks. Though the symlinks are just for shorter paths and I think unnecessary. Cygwin symlinks: /c => /cygdrive/c /dev2 => /c/dev2 (and then recurse) /cm3 => /c/cm3 (and then recurse) NTFS junctions: (I use sysinternals.com's junction.exe to set these up) \cygdrive\c => c:\ \c\cm3 => c:\cm3 (aka /c/cm3, on current drive, and win32 accepts forward slashes, voila) \c\dev2 => c:\dev2 (aka /c/cdev2, likewise) You could also setup in-memory symlinks I believe with subst and/or DefineDosDevice. This way I can cross build either from either. Just bringing up CM3/Cygwin and "staying there", I don't think requires this. Nor does starting from the distribution I provided,I think. I guess I should test that, and if I am wrong, document these as "officially" needed. (X86_CYGWIN?, X86_MINGWIN? X86_INTERIX, X86_POSIX_CYGWIN, X86_WIN32_MINGWIN, X86_POSIX_INTERIX?) I also do some path conversion in the Python wrappers. I would strongly consider the following: in cm3.exe, set the quake variables INSTALLROOT and ROOT very much like how the Python/sh/Quake code does. Something like: If the environment variable CM3_ROOT is set, set ROOT to it. If the environment variable CM3_INSTALL is set, set INSTALLROOT to it. I wouldn't mind while at it coming up with longer more clear names -- CM3_INSTALL_ROOT and CM3_SOURCE_ROOT. Convert INSTALLROOT and ROOT to what is native to cm3.exe. Possibly write the variables back out to the environment, though that should be not necessary. If M3CONFIG is set in the environment, convert it to what is native cm3.exe. For all this work, only accept full paths. That removes ambiguity since /foo is a valid Win32 path. If the environment variables are not set, CM3_INSTALL can be gleaned from cm3.exe's own path. On Windows this is from GetModuleHandleW(NULL). On other platforms, I guess argv[0]? /Possibly/ by searching $PATH for cm3.exe, but that fails if I run cm3.exe by full path and it isn't in $PATH, so no. CM3_ROOT /maybe/ should not be sniffed out. You could do it by checking for CVS directory in current working directory and then going up until CVS/Repository has no slashes, something like that. Yes, I know that is specific to using CVS, doesn't work if you are sitting elsewhere, doesn't work when another source control system is used, etc. But it is very much correct today and fast enough and when it works, is correct (ok..sitting in another CVS tree?) and makes things just a little easier to use. Automation is the name of the game, right? Otherwise we'd all be programming in assembly or ones and zeros. - Jay > To: wagner at elegosoft.com> Date: Sun, 24 Feb 2008 13:54:34 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] paths..> > Olaf, you're right:> > People who use Cygwin are used to dealing with all kinds of oddities.> > I am here reproducing "README.CYGWIN" from the top level of my M3> project (note the stuff after "IMPORTANT SECTION FOLLOWS"). In my > opinion (and I think of everyone else who appears to use NT386GNU and> also post to this mailing list) the point of Cygwin is to work as a> crutch for Unix people who really, really don't want to use Windows,> but are forced for some (probably economic) reason to do so... We> want as much Unix and as little Windows as possible, and we're willing> to jump through all sorts of hoops to get our way....> > Mika> > > #> # $Id: README.CYGWIN,v 1.3 2007/07/28 23:43:50 mika Exp $> #> > ===== Basic instructions =====> > If you are just building, not maintaining, just > > export CYGWIN=1> > before compiling.> > If you are not building as user "mika", you will have to make some> changes to Make.defs (please look at that file).> > ===== From-Scratch Installation =====> > Installing this system on Cygwin can be a little tricky. So far, it's> only been tested with the old PM3 distribution from Klagenfurt (?).> This PM3 comes on 44 "floppies" and is installed in accordance with the> instructions (in German) located at> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > Having installed the PM3 distribution, building small, self-contained > Modula-3 programs should be no problem.> > However, it is different with this software distribution. During the> build process, tools are built that are used later on in the same build> process. For various reasons, m3 "overrides" don't seem to work right on> Cygwin/PM3-Klagenfurt, so we build a "distribution" system and m3ship> everything.> > ===== IMPORTANT SECTION FOLLOWS =====> > The main thing that has to be done to simplify the work of the build> system is to make sure that DOS and Cygwin directory paths match AS> MUCH AS POSSIBLE. This is difficult, because by default, Cygwin has> a different view of the "root" of the filesystem from the standard> DOS view. Running under Cygwin, the Klagenfurt system unfortunately> sometimes takes the DOS view and sometimes takes the Cygwin view.> The situation is further complicated by the fact that Windows doesn't> have proper symbolic links.> > The saving grace is that Cygwin DOES have proper symbolic links.> The solution is therefore to make the directory structure that is desired> under DOS and then link to it from within the Cygwin hierarchy.> > Therefore:> > Move the users' home directories to > > C:\home> > and make the links as follows:> > Cygwin link DOS equivalent> /home -> /cygdrive/c/home C:\cygwin\home -> C:\home> > etc.> > The filenames are still occasionally polluted by DOS things like> backslashes and drive letters. The scripts in cygwinhacks should take> care of most of the remaining problems of this sort.> > I am not sure this system can be made to work if your system disk> is called anything other than C:. Best not to try.> > (end of README.CYGWIN)> > Olaf Wagner writes:> >Jay,> >> >I'm not really happy with NT386GNU using PathnameWin32.m3.> >In my opininion it should just use the POSIX code, whatever problems> >people will have with their installation roots. (These can be avoided> >by using the /cygdrive/... equivalents.)> >Why don't we just assume that by deafult CM3 is installed in> >/usr/local/cm3 as for all other targets (except NT386, of course)?> >> >One thing that immediately comes to mind is that all paths output> >by CM3 programs will contain \ instead of / then and thus be> >unusable for simple copy-and-paste, as \ is the escape character> >in all POSIX command line tools. So this seems kind of incompatible> >to me.> >> >Olaf> >> >Quoting Jay :> >> >> I could be wrong about many things here:> >>> >> Cygwin fopen and I presume open accepts all of:> >> c:\foo, c:/foo, /foo, \foo> >>> >> /foo and \foo probably have a different meaning between Cygwin and Win32.> >> In Win32, /foo and \foo are, well, \foo, on the current drive.> >> In Cygwin, /foo is probably /foo at the Cygwin root.> >> I'd kind of like to be wrong here, about \foo having different > >> meanings between them, since it a common form for me.> >>> >> Cygwin does not accept c:foo.> >> In Win32 c:foo is foo in the current working directory of the C: drive.> >> I don't think c:foo is used often, but it does have a meaning.> >>> >> Now, as well, cm3 has its own Path module, M3Path, but I realized > >> tonight it also uses libm3's Pathname module a fair amount. In > >> particular, I was having errors "shipping".> >>> >> This throws a big monkey wrench into where I was going.> >> So now, after a bunch of going back and forth on various uncommited > >> changes, I have now switched (and commited) NT386GNU to use > >> PathnameWin32.m3. To some extent, this strikes at the core of "what > >> is Posix" and "ruins" NT386GNU's differentiation from "NT386MINGNU". > >> However, remember that Cygwin does appear to accept Win32 paths. > >> So, again, if Cygwin accepts Win32 paths, is it Posix? (Given that > >> Win32 accepts /foo, is it Posix?) As well, this target still uses > >> cygwin1.dll for its all its odd behaviors. It still uses > >> open/read/write (again, remember that msvcrt.dll DOES expose these > >> SAME functions..I still contend that Win32 is close enough to Posix > >> to satisfy almost everyone..and then X Windows can be dealt with > >> separately maybe, or Trestle/Win32 fixed).> >>> >> I have some more testing to do but I think this switch will fly, and > >> various other options can go away.> >> And I can undo the small amount I had commited.> >> I think I'll just send my m3path.m3 diff around and then delete it.> >>> >> I ended up with a set based approach where host and target have a > >> set of dir separaters, volume separaters, and separators (union of > >> previous two). These are TINY sets, containing a maximum of three > >> characters each, and '/' is always a member of two of them. So a set > >> is kind of overkill. But it works out pretty ok.> >>> >> - Jay> >> _________________________________________________________________> >> Need to know the score, the latest news, or you need your > >> Hotmail??-get your "fix".> >> http://www.msnmobilefix.com/Default.aspx> >> >> >> >-- > >Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany> >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> > http://www.elegosoft.com | Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin> >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:32:56 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:32:56 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: It is easier than THAT today, I meant, otherwise ambiguous and I could have been saying your way is easier than mine. I'm lazy and so I try to make things easy for myself. :) - Jay From: jayk123 at hotmail.comTo: mika at async.caltech.edu; wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] paths..Date: Mon, 25 Feb 2008 08:31:47 +0000 It is easier than today I think, and might be made even easier.Unix doesn't have to be as hard as possible, though I guess I'm a heretic on this point too.Unix seems to be all about making things much harder than necessary. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:33:52 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:33:52 +0000 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Message-ID: got truncated again... Here is an unnecessarily complete explanation: The problem was Given "a../..", M3Path.FixPath wasn't doing anything. I wanted to fix that. It would collapse "a/.." or ".a/.." or "a./.." correctly, but not "a../.." I know people will disagree as to what is "correct" due to symlinks, but this was/is the behavior. Given input like "../.." it should also leave that alone, because "there is nowhere for it to go". In fixing "a../.." to collapse to nothing or ".", I also broke leaving "../.." alone. I thought the check for "is the element prior to ".." also ".."?" wasn't needed, since they get removed, left to right, and the scan is restarted for every change, but they aren't removed if "there is nowhere to go", so the check is valid. But the check wasn't right. It didn't check for a ".." element, it checked for an element ending in "..". NOW it should be treating them both correctly, as well as not indexing out of bounds for other input as it was doing.I added a check that the previous element is of length 2, and "ends" "..". Yes, I realize that elements ending in ".." but not equal to ".." are rare and not particularly interesting.Windows even has trouble with them: C:\>mkdir a.. C:\>dir a* 02/25/2008 12:11 AM a Huh? C:\>mkdir \\?\c:\a.. C:\>dir a* 02/25/2008 12:11 AM a 02/25/2008 12:12 AM a.. C:\>rmdir a.. C:\>dir a* 02/25/2008 12:12 AM a.. Huh? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:40:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:40:10 +0000 Subject: [M3devel] paths.. In-Reply-To: <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> References: Your message of "Sat, 23 Feb 2008 13:39:09 +0100." <20080223133909.1innlymk8wcswssw@mail.elegosoft.com> <200802242154.m1OLsYK5081573@camembert.async.caltech.edu> Message-ID: > process. For various reasons, m3 "overrides" don't seem to work right on ps: I believe overrides work in CM3/NT386GNU today. At least I didn't do anything to workaround them not working. buildship and upgrade and make-dist all seem to work and I believe the second two depend on overrides. I have seen overrides vary between using SL and /, but either should always work now. PathnameWin32.m3 and M3Path.m3 always recognize / as a directory separator, which is correct, unless you prefix the paths with \\? in which case it is arguably incorrect. Please do try the distribution I put out there. Or try building it yourself from current source. Thanks. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 09:50:08 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 08:50:08 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: This sounds very much how Windows has been but finally changed. It used to be in C++ you could do: try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ else catch (...) { printf("caught exception\n"); } now you can't. Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. The most common one is an "access violation". There's also "stack overflow". And others. They can be raised by code via RaiseException though. There is a similar syntax for catching them -- __try / __except. Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"? In particular, Win32 structured exceptions fall into two or three classes: Someone called RaiseException. These are orderly and reasonable to catch, but rare. (Even if C++ exceptions are implemented via RaiseException.) Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some data somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" corrupt. I suggest a NULL deref might be the third class, but not clear. If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the case, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops. What about integer overflow? I wonder. :) - Jay > To: dragisha at m3w.org> Date: Sun, 24 Feb 2008 14:24:30 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well...> > Surely the SPIN people had to do that?> > I've wanted it a few times, too.> > Mika> > =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:> >Once, there was a talk about (original?) CM3 making checked runtime> >errors behave like exceptions?> >-- > >Dragi??a Duri?? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 15:47:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 14:47:44 +0000 Subject: [M3devel] shipping with overrides? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: I understand that when you build with overrides, you can't ship. "package was built with overrides, not shipping." My question is the opposite. Why can some packages apparently ship despite being built with overrides?For example m3middle? Something obvious? Probably. Something to be debugged? - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 16:12:36 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 15:12:36 +0000 Subject: [M3devel] M3Path.FixPath rewrite? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: M3Path.FixPath had some flaws, mainly: it uses a fixed size array to store the locations of path separators in the presence of too many separators, it'd ignore stuff every occurence of . or .. causes it to restart its work (after removing it) I have written a new version with these aspects fixed. Anyone care to try it out? diff and m3path.m3 attached. There's a small test harness built in, disabled. You can feed strings through the old and new and compare. They don't always match. I think my results are "more correct". Thanks, - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: M3Path.m3 URL: From jayk123 at hotmail.com Mon Feb 25 16:38:38 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 15:38:38 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: I know this area has been brewing under the surface a while. I'll bring it up. :) Here is some apparently typical code: PROCEDURE Escape (nm: TEXT): TEXT = VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; BEGIN IF (nm = NIL) THEN RETURN NIL; END; len := Text.Length (nm); IF (len + len <= NUMBER (buf)) THEN RETURN DoEscape (nm, len, buf); ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + len)^); END; END Escape; PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF CHAR): TEXT = VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; BEGIN Text.SetChars (buf, nm); FOR i := 0 TO len-1 DO IF (buf[i] = BackSlash) THEN INC (n_escapes); END; END; IF (n_escapes = 0) THEN RETURN nm; END; src := len - 1; dest := src + n_escapes; WHILE (src > 0) DO c := buf[src]; DEC (src); buf[dest] := c; DEC (dest); IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); END; END; RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); END DoEscape;Look at how inefficient this is. For a long string it makes a heap allocation, even if in the end it makes no changes to the string. For any length string it copies it out to an array. Then if there are any changes, it copies it again, probably into heap, likely the input immediately becoming garbage. Heap allocation may be fast, but building up garbage and causing more work for the garbage collector I assume is bad. And if the string had no backslashes, it's all a big waste. I assume texts are read only? I know lots of systems have read only strings. There are pluses and minus to them. They can be single-instanced. Some systems with read only strings have another type, such as "StringBuilder" or "StringBuffer". So -- I don't have a specific question, but maybe a mutable string "class" aka "type" is needed?Not necessarily in the language but in m3core or libm3? Maybe it's already there? I just spent a few hours diddling with arrays of chars. Unfortunately they are not resizable. It was not entirely satisfactory. Besides the array I had to pass around a length and a start. Wrapping this up in one record TYPE MutableString= ... might be a good idea. For more efficient read only access, would it be reasonable for the runtime to materialize on-demand 8 bit and 16 bit representations of a string if a user calls some new thing like Text.GetDirectA (t: TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF WIDECHAR? Throw an exception if the string cannot be represented with 8 bit characters? Or use utf8? Besides, I know I'm a big predictable whiner but I like how this works in Windows.. It may not have been as seamless, but it works and it really doesn't tend to break or slow down existing code. roughly: "foo" is an 8 bit string of type char* (or const char* or possibly const char[4]) L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) "L" for "long" aka "wide" Functions must be written to specifically use one or the other. In C++ you can templatize. There is std::string and std::wstring that are template instantiations. Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc. And really there's no point in 8 bit strings. If you have a blob, that's an array of bytes or something, not characters. It works. Utf8 is another seemingly popular route but I think it's a hack. I think mostly people don't touch their code and say, voila, it's utf8, and they only really support the same old English or possibly 8 bit characters (some European characters). Granted, to some extent, this does work, as long as you don't do anything with the string but strlen, strcpy, and some others and pass it to code that does treat it correctly. Still, variably sized encodings seem like a bad idea here, and 16 bits per character seem affordable enough. And yes, I know that Unicode is actually know 20 bits per character and some characters take two wchar_ts but I try to ignore that... And I know there is a lot of existing code, but sometimes there is a need for progress too... Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:13:05 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:13:05 +0000 Subject: [M3devel] test.. In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: looks like m3commit is broken again... _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:15:34 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:15:34 +0000 Subject: [M3devel] thread.fork getting nil on nt386gnu? In-Reply-To: <20080224153541.59c105ro8e88480g@mail.elegosoft.com> References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: any obvious ideas? I'll have to pause for a bit again..Jay at jay-win1 /cygdrive/c/dev2/cm3.2/m3-ui/juno-2/juno-app/NT386GNU/Juno.exe ****** runtime error:*** Thread client error: NIL apply method passed to Thread.Fork!*** file "ThreadWin32.m3", line 578*** 14837 [sig] Juno 3908 c:\dev2\cm3.2\m3-ui\juno-2\juno-app\NT386GNU\Juno.exe: *** fatal error - called with threadlist_ix -1Hangup - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 25 19:22:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 25 Feb 2008 18:22:47 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> References: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Message-ID: This was causing NT386GNU shobjgen to crash so I went ahead and wrapped up all the globals in functions. m3commit isn't working. I'm building linuxlibc6 on birch now. Solaris is probably affected. Darwin and I think FreeBSD are not affected. And some inactive platforms -- HPUX, Irix, Linux aout 1.x. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] utime.i3 and imported dataDate: Wed, 13 Feb 2008 11:01:51 +0000 > From: hosking at cs.purdue.edu> > Aren't these all superseded by gettimeofday?> > I say just not support the global variable access.> > Utime.i3 on other platforms does not have these globals.Could be. I don't know this stuff.. They are currently used though. I didn't happen here by chance..I'll maybe poke around.I guess this is a time to send diffs and get sign off on all platforms.OR fork the file backwards to DateLinuxOld.m3, DateBsdOld.m3, move everyone to it, then fix DateLinux/Bsd to have no data and as people test their platform move forward? And the last guy turn off the lights?(This is a philosophical and real question. The first approach is slower but moves cleanly all at once from good to good. The second approach allows a gradual migration that starts right away and leaves a cluttered history in its wake but arrives at the same place, possibly but not necessarily sooner.) Anyway, my workaround I think is working.. - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 03:19:16 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 25 Feb 2008 18:19:16 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Mon, 25 Feb 2008 08:50:08 GMT." Message-ID: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Jay, Sometimes I wonder if you have never read the Green Book!!! The very first section of the Modula-3 definition, Section 2.1 of the Green Book, talks about the distinction between "checked runtime errors" and "unchecked runtime errors" and ends with the sentence "Unchecked runtime errors can occur only in unsafe modules." If I may make one of those philosophical diversions that so often lead to Language Wars (but in this case isn't intended to), you mentioned something a while back along the lines of (I am not quoting you verbatim) "every line of code is part of an application's interface, because it can cause...a change in memory usage or expose a previously unknown race condition".. The whole point of Modula-3 is that Modula-3 is part of a family of tools, a way of thinking, even, under which this isn't true. If you use the garbage collector alluded to by Knuth, timing changes in your program CANNOT cause it to run out of memory. If you use the Extended Static Checker (coded by some of the same people who did Modula-3), timing changes to your program CANNOT expose unknown race conditions because there ARE no race conditions in your program! And if you use Modula-3 the way you're supposed to---that is, use the safe features almost exclusively and use UNSAFE code so sparingly that it is obviously (i.e., provably) correct, you will have NO unchecked runtime errors! Now it is true that we live in an imperfect world, and that neither any mortal nor any product of any mortal is perfect, but the WHOLE POINT of Modula-3 is to be a stepping-stone to this type of perfection!!!! All of its users are longing to one day be programming in the Elysian Fields where there are no race conditions, heap overflows due to lazy garbage collectors, nor any unchecked runtime errors. Will we ever get there? I don't know. But for me at least, one of the reasons I use Modula-3 is because it tries, and I can see how one might fill in the gaps and get it all the way. I know of no other programming environment that comes to within several orders of magnitude of Modula-3's performance and satisfies the same properties. Integer overflow: the Green Book says that the language catches it. Implementations generally don't, as far as I know. The specification is really only fifty pages long... Mika Jay wrote: >This sounds very much how Windows has been but finally changed. > > It used to be in C++ you could do: > > try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ > else catch (...) { printf("caught exception\n"); } > > now you can't. > Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". > "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. > The most common one is an "access violation". There's also "stack overflow". And others. > They can be raised by code via RaiseException though. > > There is a similar syntax for catching them -- __try / __except. > > Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"? > In particular, Win32 structured exceptions fall into two or three classes: > Someone called RaiseException. These are orderly and reasonable to catch, but rare. > (Even if C++ exceptions are implemented via RaiseException.) > Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) > This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some dat >a somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" >corrupt. I suggest a NULL deref might be the third class, but not clear. > >If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the cas >e, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops. > >What about integer overflow? I wonder. :) > > - Jay From jayk123 at hotmail.com Tue Feb 26 01:36:49 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 00:36:49 +0000 Subject: [M3devel] test? Message-ID: Just testing..mailing lists seem down again.. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 04:01:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 03:01:50 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> References: Your message of "Mon, 25 Feb 2008 08:50:08 GMT." <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Message-ID: Mika, I do need to reread that book, yes. Most of my reading of it was years ago. Yes the odds of me confusing checked and unchecked errors are real. I think I might have speculated as to the way things really are, while talking mainly about how things perhaps are not. However..I still believe the implementation is the interface. I don't see how Modula-3 fixes that. > If you use the garbage collector alluded to by Knuth, timing changes> in your program CANNOT cause it to run out of memory. I didn't mean to necessarily link these things together. Let's say garbage is collected immedately upon it being created. A program still has a certain amount of non-garbage memory allocated at any one time, and that amount might grow or shrink as changes are made to the code. How about this backwards example: Let's say I have some code that does a heap allocation and handles arbitrarily large data. I find it is slow and I replace it with a fixed sized array. Boom, I break anyone using large data. Now, granted, this is a dumb, backwards example. But it is an implementation detail not revealed in the .i3 file. The .i3 file, like, the "binary" interface. If you get those to match, well, great, your stack won't be unbalanced, safe code will be safe, but nothing will necessarily be correct. > If you use the Extended Static Checker (coded by some of the same people > who did Modula-3), timing changes to your program CANNOT expose unknown Well...I'm ignorant of this particular checker. I am familiar with some of the static checking that is ot there. Only recently have I seen any static checking for race conditions. This is against and C and C++ code, mind you. Perhaps they "resisted" static analysis until recently, hard to parse and all that.. Anyway, while I am not an expert on static checking potential and practise, I have seen just an astounding number of "crazy" bugs and I don't see much hope for much automatic bug detection. Most of the "bugs" found by static checking are very basic things, like leaks or forgetting to check an error, and never something particularly high level as to what the code is actually supposed to do. I mean..I'm not sure this is a valid example or not, but let's say I have the functions Plus and Minus, and let's say I'm a terrible typist and I implement Plus with - and Minus with +. What static checking will catch that. Now, yes, I grant, any amount of manual dynamic testing will catch it. But I think the point is valid -- static checking never checks much. Generalized automatic checking never checks much. The best you can do is along the lines of m3-sys/tests -- a small "framework" for "running stuff" and "comparing the output against expected", perhaps being amitious and including "negative tests" (make sure erroneous source code fails to compile and gives a good error message). I guess, to put a positive light on things, the best we can hope for is some sort of composition of larger systems out of available parts that are already well tested and known to work fairly well. However, this is just..like..a fractal. Those available parts are built up out of yet again smaller well tested parts. And so on down the line. And no layer or part is free of bugs. Processors have bugs. Compilers have bugs. "operating systems" (which are really nothing special -- just another bunch of libraries) have bugs. "There are bugs everywhere". "More code => more bugs, even if that code is meant to find bugs, such as assertion failures" => people put in incorrect assertions, oops, they trigger, let's go and remove or loosen the assertion. I just don't see static checking making all that much headway against the tremendous variety of things programmers do wrong. "Safety" is a nice step, get the easy things, the buffer overflows, but that still leaves lots of room for error (look at how my "safe" m3path.m3 broke the tinderbox for example....) I think Modula-3 was very far ahead of its time. I think a lot of systems have caught up. I grant that most of the systems that have caught up might not catch all the way up, they are either not as safe or not as performant. Again, really, I think correctness is about far more than safety, and that implementation is interface, because safety or no safety, code can depend on nearly arbitrary characteristics of the code it uses. Ok, I'm repeating myself now, sorry. I don't think I see an argument here btw. Modula-3 is what it is. It solves some problems. It doesn't do the impossible. Have you used the NT386 system btw? One of the great things about Modula-3 is only parsing the headers once, and a resulting very fast compiler. However on non-NT386 the gcc backend all but ruins this perf. The integrated compiler is just way way way way faster than the gcc backend... you (all) should try it. Gotta go, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika at async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the Green Book!!!> > The very first section of the Modula-3 definition, Section 2.1 of> the Green Book, talks about the distinction between "checked runtime> errors" and "unchecked runtime errors" and ends with the sentence> "Unchecked runtime errors can occur only in unsafe modules."> > If I may make one of those philosophical diversions that so often> lead to Language Wars (but in this case isn't intended to), you> mentioned something a while back along the lines of (I am not quoting> you verbatim) "every line of code is part of an application's> interface, because it can cause...a change in memory usage or expose> a previously unknown race condition"..> > The whole point of Modula-3 is that Modula-3 is part of a family> of tools, a way of thinking, even, under which this isn't true.> > If you use the garbage collector alluded to by Knuth, timing changes> in your program CANNOT cause it to run out of memory.> > If you use the Extended Static Checker (coded by some of the same people> who did Modula-3), timing changes to your program CANNOT expose unknown> race conditions because there ARE no race conditions in your program!> > And if you use Modula-3 the way you're supposed to---that is, use the> safe features almost exclusively and use UNSAFE code so sparingly that> it is obviously (i.e., provably) correct, you will have NO unchecked> runtime errors!> > Now it is true that we live in an imperfect world, and that neither> any mortal nor any product of any mortal is perfect, but the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> perfection!!!! All of its users are longing to one day be programming> in the Elysian Fields where there are no race conditions, heap> overflows due to lazy garbage collectors, nor any unchecked runtime> errors. Will we ever get there? I don't know. But for me at> least, one of the reasons I use Modula-3 is because it tries, and> I can see how one might fill in the gaps and get it all the way.> I know of no other programming environment that comes to within> several orders of magnitude of Modula-3's performance and satisfies> the same properties.> > Integer overflow: the Green Book says that the language catches it.> Implementations generally don't, as far as I know.> > The specification is really only fifty pages long...> > Mika> > Jay wrote:> >This sounds very much how Windows has been but finally changed. > > > > It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1); } /* access violation, reading from address 1 */ > > else catch (...) { printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions". > > "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. > > The most common one is an "access violation". There's also "stack overflow". And others.> > They can be raised by code via RaiseException though.> > > > There is a similar syntax for catching them -- __try / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"?> > In particular, Win32 structured exceptions fall into two or three classes:> > Someone called RaiseException. These are orderly and reasonable to catch, but rare. > > (Even if C++ exceptions are implemented via RaiseException.) > > Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix) > > This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some dat> >a somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a NULL deref might be the third class, but not clear.> > > >If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the cas> >e, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonder. :)> > > > - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 04:47:03 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 25 Feb 2008 19:47:03 -0800 Subject: [M3devel] Do I remember well... In-Reply-To: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." Message-ID: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> I believe the main reason the compiler is slow on most platforms is that it sleeps for 0.1 seconds every time it spawns a process. My private version of the compiler has that sleep taken out and runs probably 20x faster (for a typical compile). Jay, I still say you are ignorant of a huge part of the history of Computer Science---in this you are joined by 99% of people who use computers, by the way. You should in fact not start with the Green Book, but with this: http://www.masswerk.at/algol60/report.htm And reflect upon these words (again, from "The Humble Programmer", Dijkstra's 1972 Turing Award lecture): The fourth project to be mentioned is ALGOL 60. While up to the present day FORTRAN programmers still tend to understand their programming language in terms of the specific implementation they are working with hence the prevalence of octal and hexadecimal dumps, while the definition of LISP is still a curious mixture of what the language means and how the mechanism works, the famous Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine effort to carry abstraction a vital step further and to define a programming language in an implementation-independent way. One could argue that in this respect its authors have been so successful that they have created serious doubts as to whether it could be implemented at all! The report gloriously demonstrated the power of the formal method BNF, now fairly known as Backus-Naur-Form, and the power of carefully phrased English, a least when used by someone as brilliant as Peter Naur. I think that it is fair to say that only very few documents as short as this have had an equally profound influence on the computing community. The ease with which in later years the names ALGOL and ALGOL-like have been used, as an unprotected trade mark, to lend some of its glory to a number of sometimes hardly related younger projects, is a somewhat shocking compliment to its standing. The strength of BNF as a defining device is responsible for what I regard as one of the weaknesses of the language: an over-elaborate and not too systematic syntax could now be crammed into the confines of very few pages. With a device as powerful as BNF, the Report on the Algorithmic Language ALGOL 60 should have been much shorter... [talk about parameter-passing in Algol 60] How large a data structure a given program can process is clearly part of its interface, like so: PROCEDURE A(VAR r : ARRAY OF INTEGER); (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) Whether that particular bit of information can be represented in a machine-readable form or not is open to question, but irrelevant. C and C++ don't get much in the way of static verification not because they have messy syntax but because they have poorly understood (sometimes, plainly undefined, I am told) semantics. And yes that is why they started with Modula-3. The readers and writers (Rd and Wr) libraries, as they came out of SRC, have been statically verified to be entirely free of deadlock and I believe also incorrect data accesses. I was at a talk that Greg Nelson gave about this at Caltech a few years ago, but I don't remember all the details---just that they found a few previously unknown bugs. This is what all those <* LL *> pragmas are all about. The ESC project continued with Java. I think the people are all at Microsoft now, but ESC is still available, I believe both for Modula-3 and Java (I think the Java version is still written in Modula-3). Btw, the example that Greg Nelson showed when he gave his demo (live on a laptop!) *did* catch a problem with + vs. - (well it was an array index that was off by 1, and it was caught statically, but it clearly depended on the checker's knowing about + vs. -). And yes you are right, of course, testing never shows much. Another Dijkstraism (from 1970): Program testing can be used to show the presence of bugs, but never to show their absence! It is clear that if you actually want to be certain your program is correct (and some people do, some of the time), you will have to invest in some sort of formal reasoning. In order for it to be tractable, you need simple languages, languages that are not defined by their implementations (because trying to understand that would be hopeless). If you can do that, you can at least divide your bugs into the categories "application bugs" and "language implementation bugs". It is *not* a feature or shortcoming of Modula-3 that its arithmetic rolls over instead of raising an exception on overflow. The language spec is clear on it: in Modula-3, overflows are to be checked runtime errors. It is a compiler shortcoming (or bug) that they aren't checked. And yes, Modula-3 was far ahead, in exactly the same way that Backus, Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson, Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960. But no, absolutely no one has caught up. The utterly vast majority of people who deal with computers still have absolutely no understanding of how to handle system complexity. I am sure that this sad state of affairs is familiar enough to every reader of this email that I don't have to multiply examples. Finally, I'm really not talking about language features.. safe vs. unsafe, avoidance of bus errors, etc. It's a question of tools of the human mind more than it is a question of compiler implementation and runtime systems---not, where do you want to go today? but, do you UNDERSTAND where you are going today? Remember that programming languages are for HUMANS, not computers. Computers couldn't care less what language you are programming in. In fact they would be "happier" if you just typed in the machine code directly! Mika Jay writes: >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Mika, I do need to reread that book, yes. Most of my reading of it was year= >s ago. >Yes the odds of me confusing checked and unchecked errors are real. I think= > I might have speculated as to the way things really are, while talking mai= >nly about how things perhaps are not. >=20 >However..I still believe the implementation is the interface. >I don't see how Modula-3 fixes that. >=20 >> If you use the garbage collector alluded to by Knuth, timing changes> in = >your program CANNOT cause it to run out of memory. >I didn't mean to necessarily link these things together. >Let's say garbage is collected immedately upon it being created. >A program still has a certain amount of non-garbage memory allocated at any= > one time, and that amount might grow or shrink as changes are made to the = >code. >=20 >How about this backwards example: Let's say I have some code that does a he= >ap allocation and handles arbitrarily large data. I find it is slow and I r= >eplace it with a fixed sized array. Boom, I break anyone using large data. = >Now, granted, this is a dumb, backwards example. But it is an implementatio= >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int= >erface. If you get those to match, well, great, your stack won't be unbalan= >ced, safe code will be safe, but nothing will necessarily be correct. >=20 > > If you use the Extended Static Checker (coded by some of the same people= > > who did Modula-3), timing changes to your program CANNOT expose unknown= >=20 >Well...I'm ignorant of this particular checker. I am familiar with some of = >the static checking that is ot there. Only recently have I seen any static = >checking for race conditions. This is against and C and C++ code, mind you.= > Perhaps they "resisted" static analysis until recently, hard to parse and = >all that.. Anyway, while I am not an expert on static checking potential an= >d practise, I have seen just an astounding number of "crazy" bugs and I don= >'t see much hope for much automatic bug detection. Most of the "bugs" found= > by static checking are very basic things, like leaks or forgetting to chec= >k an error, and never something particularly high level as to what the code= > is actually supposed to do. I mean..I'm not sure this is a valid example o= >r not, but let's say I have the functions Plus and Minus, and let's say I'm= > a terrible typist and I implement Plus with - and Minus with +. What stati= >c checking will catch that. Now, yes, I grant, any amount of manual dynamic= > testing will catch it. But I think the point is valid -- static checking n= >ever checks much. Generalized automatic checking never checks much. The bes= >t you can do is along the lines of m3-sys/tests -- a small "framework" for = >"running stuff" and "comparing the output against expected", perhaps being = >amitious and including "negative tests" (make sure erroneous source code fa= >ils to compile and gives a good error message). >=20 >I guess, to put a positive light on things, the best we can hope for is som= >e sort of composition of larger systems out of available parts that are alr= >eady well tested and known to work fairly well. However, this is just..like= >..a fractal. Those available parts are built up out of yet again smaller we= >ll tested parts. And so on down the line. And no layer or part is free of b= >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which = >are really nothing special -- just another bunch of libraries) have bugs. "= >There are bugs everywhere". "More code =3D> more bugs, even if that code is= > meant to find bugs, such as assertion failures" =3D> people put in incorre= >ct assertions, oops, they trigger, let's go and remove or loosen the assert= >ion. >=20 >I just don't see static checking making all that much headway against the t= >remendous variety of things programmers do wrong. "Safety" is a nice step, = >get the easy things, the buffer overflows, but that still leaves lots of ro= >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp= >le....) >=20 >I think Modula-3 was very far ahead of its time. I think a lot of systems h= >ave caught up. >I grant that most of the systems that have caught up might not catch all th= >e way up, they are either not as safe or not as performant. >=20 >Again, really, I think correctness is about far more than safety, and that = >implementation is interface, because safety or no safety, code can depend o= >n nearly arbitrary characteristics of the code it uses. >=20 >Ok, I'm repeating myself now, sorry. >=20 >I don't think I see an argument here btw. Modula-3 is what it is. It solves= > some problems. It doesn't do the impossible. >=20 >Have you used the NT386 system btw? One of the great things about Modula-3 = >is only parsing the headers once, and a resulting very fast compiler. Howev= >er on non-NT386 the gcc backend all but ruins this perf. The integrated com= >piler is just way way way way faster than the gcc backend... you (all) shou= >ld try it. >=20 >Gotta go, > - Jay > > > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika= >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the= > Green Book!!!> > The very first section of the Modula-3 definition, Sectio= >n 2.1 of> the Green Book, talks about the distinction between "checked runt= >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un= >checked runtime errors can occur only in unsafe modules."> > If I may make = >one of those philosophical diversions that so often> lead to Language Wars = >(but in this case isn't intended to), you> mentioned something a while back= > along the lines of (I am not quoting> you verbatim) "every line of code is= > part of an application's> interface, because it can cause...a change in me= >mory usage or expose> a previously unknown race condition"..> > The whole p= >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t= >hinking, even, under which this isn't true.> > If you use the garbage colle= >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t= >o run out of memory.> > If you use the Extended Static Checker (coded by so= >me of the same people> who did Modula-3), timing changes to your program CA= >NNOT expose unknown> race conditions because there ARE no race conditions i= >n your program!> > And if you use Modula-3 the way you're supposed to---tha= >t is, use the> safe features almost exclusively and use UNSAFE code so spar= >ingly that> it is obviously (i.e., provably) correct, you will have NO unch= >ecked> runtime errors!> > Now it is true that we live in an imperfect world= >, and that neither> any mortal nor any product of any mortal is perfect, bu= >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p= >erfection!!!! All of its users are longing to one day be programming> in th= >e Elysian Fields where there are no race conditions, heap> overflows due to= > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g= >et there? I don't know. But for me at> least, one of the reasons I use Modu= >la-3 is because it tries, and> I can see how one might fill in the gaps and= > get it all the way.> I know of no other programming environment that comes= > to within> several orders of magnitude of Modula-3's performance and satis= >fies> the same properties.> > Integer overflow: the Green Book says that th= >e language catches it.> Implementations generally don't, as far as I know.>= > > The specification is really only fifty pages long...> > Mika> > Jay wrot= >e:> >This sounds very much how Windows has been but finally changed. > > > = >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1= >); } /* access violation, reading from address 1 */ > > else catch (...) { = >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) = >catches all C++ exceptions but not these "Win32 structured exceptions". > >= > "Win32 structured exceptions" are generally "hardware exceptions" made vis= >ible to software. > > The most common one is an "access violation". There's= > also "stack overflow". And others.> > They can be raised by code via Raise= >Exception though.> > > > There is a similar syntax for catching them -- __t= >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly= >" and so more "catchable"?> > In particular, Win32 structured exceptions fa= >ll into two or three classes:> > Someone called RaiseException. These are o= >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i= >mplemented via RaiseException.) > > Someone has some corrupted data and "ac= >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more = >common case, and if you catch such an exception, you have to wonder, uh, so= >me data is corrupt..which data? What can I possily do at this point, given = >that some dat> >a somewhere is corrupt? It could be the heap. It could be t= >he stack. It could be something small that I'm not going to touch. Heck, ma= >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N= >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a= >n adequate job of noticing things as soon as they have gone bad, and not at= > an indeterminate point afterward, that sounds more viable. I suspect this = >might be the cas> >e, as long as you haven't called out to some buggy C cod= >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde= >r. :)> > > > - Jay=20 >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Mika, I do need to reread that book, yes. Most of= > my reading of it was years ago.
>Yes the odds of me confusing checked and unchecked errors are real. I think= > I might have speculated as to the way things really are, while talking mai= >nly about how things perhaps are not.
> 
>However..I still believe the implementation is the interface.
>I don't see how Modula-3 fixes that.
> 
>> If you use the garbage collector alluded to by Knuth, timing changesR>> in your program CANNOT cause it to run out of memory.

>I didn't mean to necessarily link these things together.
>Let's say garbage is collected immedately upon it being created.
>A program still has a certain amount of non-garbage memory allocated at any= > one time, and that amount might grow or shrink as changes are made to the = >code.
> 
>How about this backwards example: Let's say I have some code that does a he= >ap allocation and handles arbitrarily large data. I find it is slow and I r= >eplace it with a fixed sized array. Boom, I break anyone using large data. = >Now, granted, this is a dumb, backwards example. But it is an implementatio= >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int= >erface. If you get those to match, well, great, your stack won't be unbalan= >ced, safe code will be safe, but nothing will necessarily be correct.
> 
> > If you use the Extended Static Checker (coded by some of the sam= >e people
 > who did Modula-3), timing changes to your program C= >ANNOT expose unknown

>Well...I'm ignorant of this particular checker. I am familiar with some of = >the static checking that is ot there. Only recently have I seen any static = >checking for race conditions. This is against and C and C++ code, mind you.= > Perhaps they "resisted" static analysis until recently, hard to parse and = >all that.. Anyway, while I am not an expert on static checking potential an= >d practise, I have seen just an astounding number of "crazy" bugs and I don= >'t see much hope for much automatic bug detection. Most of the "bugs" found= > by static checking are very basic things, like leaks or forgetting to chec= >k an error, and never something particularly high level as to what the code= > is actually supposed to do. I mean..I'm not sure this is a valid example o= >r not, but let's say I have the functions Plus and Minus, and let's say I'm= > a terrible typist and I implement Plus with - and Minus with +. What stati= >c checking will catch that. Now, yes, I grant, any amount of manual dynamic= > testing will catch it. But I think the point is valid -- static checking n= >ever checks much. Generalized automatic checking never checks much. The bes= >t you can do is along the lines of m3-sys/tests -- a small "framework" for = >"running stuff" and "comparing the output against expected", perhaps being = >amitious and including "negative tests" (make sure erroneous source code fa= >ils to compile and gives a good error message).
> 
>I guess, to put a positive light on things, the best we can hope for is som= >e sort of composition of larger systems out of available parts that are alr= >eady well tested and known to work fairly well. However, this is just..like= >..a fractal. Those available parts are built up out of yet again smaller we= >ll tested parts. And so on down the line. And no layer or part is free of b= >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which = >are really nothing special -- just another bunch of libraries) have bugs. "= >There are bugs everywhere". "More code =3D> more bugs, even if that code= > is meant to find bugs, such as assertion failures" =3D> people put in i= >ncorrect assertions, oops, they trigger, let's go and remove or loosen the = >assertion.
> 
>I just don't see static checking making all that much headway against the t= >remendous variety of things programmers do wrong. "Safety" is a nice step, = >get the easy things, the buffer overflows, but that still leaves lots of ro= >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp= >le....)
> 
>I think Modula-3 was very far ahead of its time. I think a lot of systems h= >ave caught up.
>I grant that most of the systems that have caught up might not catch all th= >e way up, they are either not as safe or not as performant.
> 
>Again, really, I think correctness is about far more than safety, and that = >implementation is interface, because safety or no safety, code can depend o= >n nearly arbitrary characteristics of the code it uses.
> 
>Ok, I'm repeating myself now, sorry.
> 
>I don't think I see an argument here btw. Modula-3 is what it is. It solves= > some problems. It doesn't do the impossible.
> 
>Have you used the NT386 system btw? One of the great things about Modula-3 = >is only parsing the headers once, and a resulting very fast compiler. Howev= >er on non-NT386 the gcc backend all but ruins this perf. The integrated com= >piler is just way way way way faster than the gcc backend... you (all) shou= >ld try it.
> 
>Gotta go,
> - Jay


> >
>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18= >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
= >>
> Sometimes I wonder if you have never read the Green Book!!!R>>
> The very first section of the Modula-3 definition, Section = >2.1 of
> the Green Book, talks about the distinction between "checked= > runtime
> errors" and "unchecked runtime errors" and ends with the s= >entence
> "Unchecked runtime errors can occur only in unsafe modules.= >"
>
> If I may make one of those philosophical diversions that= > so often
> lead to Language Wars (but in this case isn't intended to= >), you
> mentioned something a while back along the lines of (I am no= >t quoting
> you verbatim) "every line of code is part of an applicati= >on's
> interface, because it can cause...a change in memory usage or = >expose
> a previously unknown race condition"..
>
> The = >whole point of Modula-3 is that Modula-3 is part of a family
> of too= >ls, a way of thinking, even, under which this isn't true.
>
> = >If you use the garbage collector alluded to by Knuth, timing changes
>= >; in your program CANNOT cause it to run out of memory.
>
> If= > you use the Extended Static Checker (coded by some of the same people
&= >gt; who did Modula-3), timing changes to your program CANNOT expose unknown= >
> race conditions because there ARE no race conditions in your progr= >am!
>
> And if you use Modula-3 the way you're supposed to---t= >hat is, use the
> safe features almost exclusively and use UNSAFE cod= >e so sparingly that
> it is obviously (i.e., provably) correct, you w= >ill have NO unchecked
> runtime errors!
>
> Now it is tr= >ue that we live in an imperfect world, and that neither
> any mortal = >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo= >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All= > of its users are longing to one day be programming
> in the Elysian = >Fields where there are no race conditions, heap
> overflows due to la= >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev= >er get there? I don't know. But for me at
> least, one of the reasons= > I use Modula-3 is because it tries, and
> I can see how one might fi= >ll in the gaps and get it all the way.
> I know of no other programmi= >ng environment that comes to within
> several orders of magnitude of = >Modula-3's performance and satisfies
> the same properties.
> <= >BR>> Integer overflow: the Green Book says that the language catches it.= >
> Implementations generally don't, as far as I know.
>
>= >; The specification is really only fifty pages long...
>
> Mik= >a
>
> Jay wrote:
> >This sounds very much how Windows= > has been but finally changed.
> >
> > It used to be in= > C++ you could do:
> >
> > try { printf("%s\n", (char*)= > 1); } /* access violation, reading from address 1 */
> > else ca= >tch (...) { printf("caught exception\n"); }
> >
> > now= > you can't.
> > Now catch (...) catches all C++ exceptions but no= >t these "Win32 structured exceptions".
> > "Win32 structured exce= >ptions" are generally "hardware exceptions" made visible to software.
&= >gt; > The most common one is an "access violation". There's also "stack = >overflow". And others.
> > They can be raised by code via RaiseExc= >eption though.
> >
> > There is a similar syntax for cat= >ching them -- __try / __except.
> >
> > Now, maybe Modu= >la-3 runtime errors are "more orderly" and so more "catchable"?
> >= >; In particular, Win32 structured exceptions fall into two or three classes= >:
> > Someone called RaiseException. These are orderly and reasona= >ble to catch, but rare.
> > (Even if C++ exceptions are implement= >ed via RaiseException.)
> > Someone has some corrupted data and "= >access violated" (aka: some sort of signal/tap on Unix)
> > This = >is the more common case, and if you catch such an exception, you have to wo= >nder, uh, some data is corrupt..which data? What can I possily do at this p= >oint, given that some dat
> >a somewhere is corrupt? It could be t= >he heap. It could be the stack. It could be something small that I'm not go= >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >> >corrupt. I suggest a NULL deref might be the third class, but not= > clear.
> >
> >If Modula-3 does an adequate job of notic= >ing things as soon as they have gone bad, and not at an indeterminate point= > afterward, that sounds more viable. I suspect this might be the cas
>= >; >e, as long as you haven't called out to some buggy C code or some uns= >afe Modula-3, oops.
> >
> >What about integer overflow? = >I wonder. :)
> >
> > - Jay


Climb to = >the top of the charts!=A0Play the word scramble challenge with star power. = >textlink_jan' target=3D'_new'>Play now! >= > >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- From jayk123 at hotmail.com Tue Feb 26 08:07:49 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 07:07:49 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> References: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> Message-ID: Mika you underestimate me somewhat but maybe not entirely. I have never used Algol.I should do a bit more research. BNF to me is, you know, like a grammar, LALR, LL, yacc, PCCTS, whatever. It is very useful step, a very good way to state what it states.But as I understand only describes syntax and not semantics. I could say is:English: subject verb [and verb]*Jay sits. okJay stands. okJay gallops. Syntactically correct but not semantically. Jay is not a horse.It is not type correct. Programming languages catch these errors usually,you don't need "extended static checking".Or you could be type correct but still wrong:Jay dies and lives. Something has to know that living cannot occur after dying.How do I state that? I think C++ is actually underappreciated here.Stroupstrup alludes to a style of programming where all side affectsare via constructor calls. I believe this is "very functional".I haven't yet seen anyone elaborate on this.Add type safety to that."Jay = Jay->die()" would return a subtype of human_t that does not have the live() method.Type checking can possibly do a lot of this.(sorry this is so morbid, I had to think of operations that could not go in acertain sequqence. I guess a better one would be Jay learns to program and Jay is born.) Being syntactically correct is a necessary first step, and thencomes type safety, and then comes actually doing what is intended. Maybe BNF has more features than I assume. I have been exposed to multiple opposing views, such as: as you say -- programs are for people first, computers second The SICP book was very interesting.. and the contrary -- performance, performance, performance Too much abstraction and you lose touch with the machine that doesultimately have to run your creation and if it is runs it too slowly,well, that does matter. (Humans are not going to run your program after all; they are much too slow.) I have a lot of real world practical experience.Not as much maybe as I should but a lot. > How large a data structure a given program can process is clearly > part of its interface, like so: > PROCEDURE A(VAR r : ARRAY OF INTEGER); > (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) Your example proves my point. The "specification" is a comment written in English.Nothing will check it. It might change. Worse, the level of detail in a commentis totally up to the programmer. If the comment was missing, what would theinterface be? That the function does nothing? I contend that there is no language that can state the complete specification.The language of the implementation comes close, however it then rests on what is below it,and so on down the line. Science has apparently figured out enough that "and so on downthe line" doesn't go all that far. We know the computer is digital, 0s and 1s, we don't haveto talk about how the transistors work to spec a function. I will look into the sleep.Can it not be a, um, a wait? You know, wait specifically for the process to exit?At the same time as reading its stdout and stderr?Actually I have some experience here...It turns out, on Windows, that it is very easy to deadlock writing code like this.There about three simple patterns, one that deadlocks, two that don't. pseudo code: 1)process = CreateProcess();if process not done read some from stdout echo it to my stdout read some from stderr echo it to my stderr This can deadlock.IF the child process ONLY writes to one of stdout or stderr, I think no deadlock.But if it writes to both, can deadlock. 2)process = CreateProcesscreate another thread (or have one already created waiting for work to do)optionally create another thread for symmetry of implementation, but inefficienthave one thread read/echo stderr, the other read/echo stdoutThis won't deadlock. 3)create the process such that stdout and stderr are the samethen just read that one pipe/handle/file/whatever, on one thread I guess, I have to check, I think on Windows you do like WaitForMultipleObjects(2, [pipe and process]).I have to check if the pipe is signaled by having data available. And then I have to look into what Posix offers here.Maybe have NT386GNU not use Posix here, however..having tried this for "serial", having done it with Thread,the various implementation pieces are not always so easily mixed and matched.For example PosixFile wants PosixScheduler, which is not usually "with" ThreadWin32, but I put in a dummy one. Having both FileWin32 and FilePosix available, with one being the revealer of File.T would be good.I think this is a simple restructuring of the code. Knowing the machine model and how your code ends up executing on the machine is not at all a bad thing.Being careful with how large the abstraction layers you build is not a bad thing.Making a compromise between human and computer is not a bad thing.I long ago gave up writting in assembly, after all.However I am constantly viewing assembly, partly by dumb virtue of how my debugger works, butalso partly because there are bugs everywhere and everything you hide from me is an opportunityfor you to hide the bug I am looking for. Every abstraction you build is something that is going to have bugs in it that I'm going to have to debug. The less abstraction, the thinner the layers, the less debugging will be needed. But yet you do absolutely need abstraction. There is this term -- "leaky abstraction".Most abstractions leak underlying details, there it is useful to understand as much of the stack as possible. Yes, I understand, it is important to know what is an implementation detail and what is an interface/behavioralguarantee. They are often blurred. One of the things good about Modula-3 is its "portability". The fact that I can do roughly the same things already on NT386, PPC_DARWIN, PPC_LINUX "keeps my honest".I can fairly readily check my work on three kind of different systems. The counterpoint here however is that at the C level and above, all machines are converging ontwo and only two models -- Windows and Posix.Portability is becoming like English. Or English and French.Rather than come up with some very very broad commonality that you believe will be implementableon forseeable architectures, you merely have to fit only two common cases.Or heck, if Cygwin flies, only one common case.(Btw, AMD64_MINGWIN should be fairly easy to implement today, AMD64_CYGWIN not so much.There are already AMD64 MinGWin distributes. Cygwin is loaded with assembly cod and the FAQ/docsare not optimistic about AMD64. So Cygwin isn't clearly a way forward.The integrated backend of course needs work and should be viable.) Yes I know LL is about static checking of locking, though I don't know how to read/write the pragmas.I also noticed the large or lm3 or whatnot files.I should look into what they can state and check. I relatively recently amassed a fairly large collection of compilers in order to "test portability".Man it is a bit sad. CFront based C++ compilers are awful. Only one return statement per functionor something. Maybe this experiment went overboard and there's a smaller number of interestingmodern tools.. Most of the stuff that is left "undefined" in C is very reasonable to leave undefined.For example, signed integer encoding is not specified.Things like going out of bounds on arrays is probably not specified.The reason is obvious -- because it is expensive to check.I have heard of code accidentally depending on array bounds overflow.Two local variables, one could overflow into the other, accidentally doubling the capacity of the program! > in this you are joined by 99% of people who use computers Equating a PROGRAMMER with 99% of computer USERS is very insulting.Really.The family/relative tech support I do..."click the whatever." "Right click or left click?"I have had that question so many times. Good thing three button mice are not prevalent. :)(and please don't insult whoever asked me that question..) The rude thing to wonder here is something about practicality vs. theory....The Modula-3 is actually squarely in the practical camp.What with having the compiler and garbage collector implemented it, for starters. I have used Scheme btw, and I was very enamored of it.Then I started debugging some of it by stepping through STk.Man every other instruction was a type check. Despite that 99% of the type checksall succeeded, or had even already succeeded against that data.It's a great programming model, but perhaps? too difficult to implement efficiently?I don't know. One hole in my experience is working with or implementing systems that infer types,except as a user of C++ templates, which does involve a significant amount of type inference.But it's not e.g. SML or a high end efficient compilation Scheme/Lisp. Meanwhile, the mailing lists are still down. Later, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s ago.> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> If you use the garbage collector alluded to by Knuth, timing changes> in => >your program CANNOT cause it to run out of memory.> >I didn't mean to necessarily link these things together.> >Let's say garbage is collected immedately upon it being created.> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > If you use the Extended Static Checker (coded by some of the same people=> > > who did Modula-3), timing changes to your program CANNOT expose unknown=> >=20> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.> >=20> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >Gotta go,> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked runtime errors can occur only in unsafe modules."> > If I may make => >one of those philosophical diversions that so often> lead to Language Wars => >(but in this case isn't intended to), you> mentioned something a while back=> > along the lines of (I am not quoting> you verbatim) "every line of code is=> > part of an application's> interface, because it can cause...a change in me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=> >, and that neither> any mortal nor any product of any mortal is perfect, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-3 is because it tries, and> I can see how one might fill in the gaps and=> > get it all the way.> I know of no other programming environment that comes=> > to within> several orders of magnitude of Modula-3's performance and satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >This sounds very much how Windows has been but finally changed. > > > => >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=> >); } /* access violation, reading from address 1 */ > > else catch (...) { => >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) => >catches all C++ exceptions but not these "Win32 structured exceptions". > >=> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more => >common case, and if you catch such an exception, you have to wonder, uh, so=> >me data is corrupt..which data? What can I possily do at this point, given => >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n adequate job of noticing things as soon as they have gone bad, and not at=> > an indeterminate point afterward, that sounds more viable. I suspect this => >might be the cas> >e, as long as you haven't called out to some buggy C cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.
> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.
> > 
> >However..I still believe the implementation is the interface.
> >I don't see how Modula-3 fixes that.
> > 
> >> If you use the garbage collector alluded to by Knuth, timing changes >R>> in your program CANNOT cause it to run out of memory.

> >I didn't mean to necessarily link these things together.
> >Let's say garbage is collected immedately upon it being created.
> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.
> > 
> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.
> > 
> > > If you use the Extended Static Checker (coded by some of the sam=> >e people
 > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown

> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).
> > 
> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.
> > 
> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)
> > 
> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.
> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.
> > 
> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.
> > 
> >Ok, I'm repeating myself now, sorry.
> > 
> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.
> > 
> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.
> > 
> >Gotta go,
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
=> >>
> Sometimes I wonder if you have never read the Green Book!!! >R>>
> The very first section of the Modula-3 definition, Section => >2.1 of
> the Green Book, talks about the distinction between "checked=> > runtime
> errors" and "unchecked runtime errors" and ends with the s=> >entence
> "Unchecked runtime errors can occur only in unsafe modules.=> >"
>
> If I may make one of those philosophical diversions that=> > so often
> lead to Language Wars (but in this case isn't intended to=> >), you
> mentioned something a while back along the lines of (I am no=> >t quoting
> you verbatim) "every line of code is part of an applicati=> >on's
> interface, because it can cause...a change in memory usage or => >expose
> a previously unknown race condition"..
>
> The => >whole point of Modula-3 is that Modula-3 is part of a family
> of too=> >ls, a way of thinking, even, under which this isn't true.
>
> => >If you use the garbage collector alluded to by Knuth, timing changes
>=> >; in your program CANNOT cause it to run out of memory.
>
> If=> > you use the Extended Static Checker (coded by some of the same people
&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> >
> race conditions because there ARE no race conditions in your progr=> >am!
>
> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the
> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that
> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked
> runtime errors!
>
> Now it is tr=> >ue that we live in an imperfect world, and that neither
> any mortal => >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All=> > of its users are longing to one day be programming
> in the Elysian => >Fields where there are no race conditions, heap
> overflows due to la=> >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev=> >er get there? I don't know. But for me at
> least, one of the reasons=> > I use Modula-3 is because it tries, and
> I can see how one might fi=> >ll in the gaps and get it all the way.
> I know of no other programmi=> >ng environment that comes to within
> several orders of magnitude of => >Modula-3's performance and satisfies
> the same properties.
> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> >
> Implementations generally don't, as far as I know.
>
>=> >; The specification is really only fifty pages long...
>
> Mik=> >a
>
> Jay wrote:
> >This sounds very much how Windows=> > has been but finally changed.
> >
> > It used to be in=> > C++ you could do:
> >
> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */
> > else ca=> >tch (...) { printf("caught exception\n"); }
> >
> > now=> > you can't.
> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions".
> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software.
&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.
> > They can be raised by code via RaiseExc=> >eption though.
> >
> > There is a similar syntax for cat=> >ching them -- __try / __except.
> >
> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?
> >=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:
> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare.
> > (Even if C++ exceptions are implement=> >ed via RaiseException.)
> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix)
> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat
> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.
> >
> >If Modula-3 does an adequate job of notic=> >ing things as soon as they have gone bad, and not at an indeterminate point=> > afterward, that sounds more viable. I suspect this might be the cas
>=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.
> >
> >What about integer overflow? => >I wonder. :)
> >
> > - Jay


Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => > >textlink_jan' target=3D'_new'>Play now!> >=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Feb 26 11:00:54 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 26 Feb 2008 11:00:54 +0100 Subject: [M3devel] CM3 package dependicies Message-ID: <1204020054.7354.2.camel@hias.m3w.org> I am trying to figure out systematic way to map dependicies of packages so I can make nice hierarchy for RPM building... It's not too hard to map it out from m3makefiles, but it will be much better if someone already solved it :). Is there such a map already out there? TIA, dd -- Dragi?a Duri? From wagner at elegosoft.com Tue Feb 26 11:36:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:36:07 +0100 Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Quoting Jay : > M3Path.FixPath had some flaws, mainly: it uses a fixed size array > to store the locations of path separators in the presence of too > many separators, it'd ignore stuff every occurence of . or .. > causes it to restart its work (after removing it) > I have written a new version with these aspects fixed. > Anyone care to try it out? > diff and m3path.m3 attached. > There's a small test harness built in, disabled. > You can feed strings through the old and new and compare. > They don't always match. I think my results are "more correct". Sorry, it will take some time till I can test these. Why don't you add the test to the package test framework in m3-sys/cm3/tests/src/TestM3Path or similar? Provide a list of input paths and expected output in files; this will make things easier to understand for others. If you add the tests first and wait one day until checking in your change we can see the impacts in the package test results in our tinderbox. Generally I think we should start adding tests for everything we change; there's so much breakage that can be avoided this 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 wagner at elegosoft.com Tue Feb 26 11:45:51 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:45:51 +0100 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <20080226114551.2b0icwj0g4ocw4wg@mail.elegosoft.com> Quoting Jay : > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > I assume texts are read only? Yes. > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed?Not necessarily in the language but in > m3core or libm3? > Maybe it's already there? For string construction you can use TextWr.T. I wouldn't object to a mutable string type as an extension though; but it won't be too easy to design. Unless you are willing to suggest some interface, we should just add this issue to the long-term TODO list. I'd rather prefer getting everything more stable again. The more tests I try to add to the regression, the more problems show up :-/ Olaf > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > _________________________________________________________________ > Helping your favorite cause is as easy as instant messaging. You IM, we give. > http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 26 11:55:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 26 Feb 2008 11:55:09 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: <1204020054.7354.2.camel@hias.m3w.org> References: <1204020054.7354.2.camel@hias.m3w.org> Message-ID: <20080226115509.oqmdrn0ruo00gwog@mail.elegosoft.com> Quoting Dragi?a Duri? : > I am trying to figure out systematic way to map dependicies of packages > so I can make nice hierarchy for RPM building... It's not too hard to > map it out from m3makefiles, but it will be much better if someone > already solved it :). Is there such a map already out there? Elego ComPact had programs to extract package dependencies (m3dep) and build dependency graphs for projects. I had already started to add some of the old stuff to my local CM3 workspace, but it will take some time until it's ready to commit. I'm currently stuck in libm3 tests automation. I was thinking of adding a simplified and M3-specific version of the ComPact project manager as alternative or replacement to the various build scripts. That's still some work though, and I haven't got much 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 hendrik at topoi.pooq.com Tue Feb 26 17:33:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 26 Feb 2008 11:33:12 -0500 Subject: [M3devel] Do I remember well... In-Reply-To: References: <200802260219.m1Q2JGj1026951@camembert.async.caltech.edu> Message-ID: <20080226163312.GA14499@topoi.pooq.com> On Tue, Feb 26, 2008 at 03:01:50AM +0000, Jay wrote: > > I just don't see static checking making all that much headway against the tremendous variety of things programmers do wrong. "Safety" is a nice step, get the easy things, the buffer overflows, but that still leaves lots of room for error (look at how my "safe" m3path.m3 broke the tinderbox for example....) Static checking is a huge help. Every error caught by a static check is an error clearly and effectively reported to you. You don't have to spend time analysing the run-time behaviour of your program to figure out what's wrong. Granted, there are still lots of things to do wrong. Run-time checks (with garbage collection) help further by enforcing the abstract-machine model of the language. This means that you never have wild pointers or out-of-bounds subscripts in a data structure in one part of a program wreaking havoc on an unrelated part. And those bugs can take *days* to track down. No. These things don't solve all problems. They don't ensure program correctness. But they sure make it easy to track down most problems. -- hendrik From jayk123 at hotmail.com Tue Feb 26 18:39:06 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 17:39:06 +0000 Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite? In-Reply-To: <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: I can't argue adding tests per change is a good idea. I was on a team where at least every bug fix had to come with an automatic regression test, if not every initial change, though of course, you could do the second. My problem historically has been lack of a framework -- how to write tests, how to run them, how to verify them, how to debug them. m3-sys\m3tests appears to be a plenty adequate framework for locally authoring, running, verifying, debugging, plus the tinderbox for ongoing status (not that, as far as I know, the tinderbox is debuggable in-situ, but still, this is plenty). I submitted the change but disabled. It's now a very small diff to enable What is the story on exposing internals to testing though? I see several options, all with pluses and minus: Expose more stuff in the .i3 file. Possibly with names like "Internal" or "Test" in them. Not great but easy and works. Invoke test code from module initialization having checked Params for M3testfoo or such. Not great but easy and often works. Adds unnecessary code to the runtime. Getting better I think: Add FooInternal.i3 or FooTest.i3. Export it from Foo.m3. I guess even to the pkg store? Call it from the text executable (also want to call FooTest.m3). This still exposes internals to callers, but at least with a clear distinction of what is internal or not. I guess another name here is FooFriend.i3. For that matter, split off the testable code into FooTest.m3. Same thing? Somehow "preprocess" the code to extract parts you want to call from test code. I'm not keen on designing a preprocessor. Aha, combine the last few? Split up Foo.m3 into FooTest.m3 and Foo.m3. Both exports only parts of Foo.i3, which is unchanged. Add FooTest.i3 that is empty? "Preprocessing" becomes a) copy an .m3 file b) replace an .i3 file (FooTest.i3)? There, I designed preprocessing, as file copying. There's also the matter of chosing the test cases that matter and not just a bunch of random strings that are obviously handled correctly but I guess just err toward throwing in more strings. - Jay > Date: Tue, 26 Feb 2008 11:36:07 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite?> > Quoting Jay :> > > M3Path.FixPath had some flaws, mainly: it uses a fixed size array > > to store the locations of path separators in the presence of too > > many separators, it'd ignore stuff every occurence of . or .. > > causes it to restart its work (after removing it)> > I have written a new version with these aspects fixed.> > Anyone care to try it out?> > diff and m3path.m3 attached.> > There's a small test harness built in, disabled.> > You can feed strings through the old and new and compare.> > They don't always match. I think my results are "more correct".> > Sorry, it will take some time till I can test these.> > Why don't you add the test to the package test framework> in m3-sys/cm3/tests/src/TestM3Path or similar?> Provide a list of input paths and expected output in files;> this will make things easier to understand for others.> If you add the tests first and wait one day until checking in> your change we can see the impacts in the package test results> in our tinderbox.> > Generally I think we should start adding tests for everything we> change; there's so much breakage that can be avoided this 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> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 18:47:31 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 17:47:31 +0000 Subject: [M3devel] cross "compiling" In-Reply-To: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> References: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> Message-ID: This may be obvious to everyone and so inadequate as to be useless, but I just had a minor idea and proved it correct. Even if you don't have a backend, C compiler, linker, etc, you can still compile the Modula-3 code for any target from any target. If you just put return 0 in the config file for backend, compile_c, link, make_lib, assembly, you can at least run the front/middle ends. For example I just compiled m3core and libm3 for Solaris. That would have caught my DatePosix.m3 error, though that sort of change was maybe one that just can't be commited without an available machine. (I'm still not sure how to do these things. You can only change what you have, or send diffs around and wait for the all clear, or you can make a best effort and hope..) Obviously it only affords a certain minimal amount of checking. But it is perhaps something. IN FACT...maybe it is enough testing that the tinderboxes should do it, for all platforms deemed "supported"? I don't think you can ship, but you can buildlocal. (I built libm3, depends on m3core). I'll push this a bit further. IF this is deemed useful, maybe a compiler switch? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Feb 26 19:34:28 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 26 Feb 2008 12:34:28 -0600 Subject: [M3devel] Is the climate right for a new promotion? Message-ID: <47C45BB4.40009@wichita.edu> I have been thinking lately that the climate might be right for a new attempt to promote Modula 3. I see two major trends and a small one that suggest this. Fist, probably nearly once week on the average, I see new articles that say that software developers are not prepared to utilize the now- proliferating multi-core processors. This actually greatly surprises me, because I had lots of exposure, decades ago, to all the concurrent programming stuff--threads, synchronization, scheduling, etc. But apparently, most programmers have been doing strictly sequential programming, and I have to admit, I myself only use concurrent programming techniques a minority of the time. In Modula-3, we have a language that already has better support than most, and certainly better than all the popular languages. Moreover, the implementation is out if front too, with Tony's recent thread and GC work for multi-processors. There are also a few articles out there that say, in effect, it is hopeless to implement threads and synchronization correctly as library code on top of existing C/C++. Second, the expansion of the internet and its vulnerability to automated attacks from anywhere in the world has greatly upped the ante on correctness of software. Before, it was enough if a program handled all the realistic cases that a reasonable user would present it with. Now, the whole theoretical space of inputs has to be handled with at least some level of correctness to avoid vulnerabilities. 1000-byte passwords are the standard example. All this means the limits of testing as a means of finding the bugs are a far greater obstacle than they once were. This makes the time right for another push toward static languages, which were somewhat of a popular flop the first time. Third, and perhaps rather more narrow, the developers of safety- critical software are reexamining the value of testing in the light of various close-calls, for example in airplanes. They are starting to look again at static methods. We have a language which, though little-known, is already designed and implemented and has a lot of convincing history. It has a lot of things that can be promoted. Aside from good thread support and the best safety properties around, it is much simpler than almost anything, yet more powerful than almost anything. A serious push would probably need the support of some large company or organization. But I think the climate is better than it has been in decades, and the technical arguments are very strong. -- ------------------------------------------------------------- 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 Tue Feb 26 19:19:53 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:19:53 +0000 Subject: [M3devel] cross "compiling" In-Reply-To: References: <20080226090813.m62v0jl6y1cccco0@mail.elegosoft.com> Message-ID: e.g. I can get this far in scripts/python/do-cm3-all.py: --- building in SOLgnu --- <== SOLgnu /cygdrive/C/dev2/cm3.2/m3-tools/m3bundle/SOLgnu/m3bundle -name B -F/cygdrive/c/DOCUME~1/Jay/LOCALS~1/Temp/qkunable to open file for reading: ../SOLgnu/B.i3: errno=2unable to open file for reading: ../SOLgnu/B.m3: errno=2 and yes I understand the problem and I think you can trivially override it by using the "correct" host m3bundle instead of the "just built" one. (might have had to make a change to skip tapi) (and I should be able to run X86_SOLARIS in a virtual machine...) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 17:47:31 +0000Subject: [M3devel] cross "compiling" This may be obvious to everyone and so inadequate as to be useless, but I just had a minor idea and proved it correct. Even if you don't have a backend, C compiler, linker, etc, you can still compile the Modula-3 code for any target from any target. If you just put return 0 in the config file for backend, compile_c, link, make_lib, assembly, you can at least run the front/middle ends. For example I just compiled m3core and libm3 for Solaris. That would have caught my DatePosix.m3 error, though that sort of change was maybe one that just can't be commited without an available machine. (I'm still not sure how to do these things. You can only change what you have, or send diffs around and wait for the all clear, or you can make a best effort and hope..) Obviously it only affords a certain minimal amount of checking.But it is perhaps something. IN FACT...maybe it is enough testing that the tinderboxes should do it, for all platforms deemed "supported"?I don't think you can ship, but you can buildlocal. (I built libm3, depends on m3core). I'll push this a bit further. IF this is deemed useful, maybe a compiler switch? - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 19:29:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 13:29:28 -0500 Subject: [M3devel] thread.fork getting nil on nt386gnu? In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> <20080224153541.59c105ro8e88480g@mail.elegosoft.com> Message-ID: <6346DE25-6495-49D0-A990-F48B989218AC@cs.purdue.edu> Looks like a corrupted/uninitialized type (method table contains a NIL pointer...). 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 Feb 25, 2008, at 1:15 PM, Jay wrote: > any obvious ideas? I'll have to pause for a bit again.. > > Jay at jay-win1 /cygdrive/c/dev2/cm3.2/m3-ui/juno-2/juno-app/NT386GNU/ > Juno.exe > > *** > *** runtime error: > *** Thread client error: NIL apply method passed to Thread.Fork! > *** file "ThreadWin32.m3", line 578 > *** > 14837 [sig] Juno 3908 c:\dev2\cm3.2\m3-ui\juno-2\juno-app\NT386GNU > \Juno.exe: * > ** fatal error - called with threadlist_ix -1 > Hangup > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 19:35:33 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:35:33 +0000 Subject: [M3devel] Do I remember well... In-Reply-To: <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> References: Your message of "Tue, 26 Feb 2008 03:01:50 GMT." <200802260347.m1Q3l3Re029234@camembert.async.caltech.edu> Message-ID: Hey I accidentally mostly confirmed this. I changed the backend to just "touch" and it too is slow. Now, granted, vfork in Cygwin is the same as fork, and does a big memory copy, so it could be that running anything in Cygwin is slow. But I could compare to other platforms..or just try removing it. Removing this is easy, at least for PTHREADS, right? And "user threads", can, at worst, do the sleep in their specific code? I think it might be good to run cm3cg and maybe as only once per directory besides, with all the files at once, or at least a few at time, or with a response file. Thanks, - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s ago.> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> If you use the garbage collector alluded to by Knuth, timing changes> in => >your program CANNOT cause it to run out of memory.> >I didn't mean to necessarily link these things together.> >Let's say garbage is collected immedately upon it being created.> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > If you use the Extended Static Checker (coded by some of the same people=> > > who did Modula-3), timing changes to your program CANNOT expose unknown=> >=20> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.> >=20> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >Gotta go,> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked runtime errors can occur only in unsafe modules."> > If I may make => >one of those philosophical diversions that so often> lead to Language Wars => >(but in this case isn't intended to), you> mentioned something a while back=> > along the lines of (I am not quoting> you verbatim) "every line of code is=> > part of an application's> interface, because it can cause...a change in me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=> >, and that neither> any mortal nor any product of any mortal is perfect, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-3 is because it tries, and> I can see how one might fill in the gaps and=> > get it all the way.> I know of no other programming environment that comes=> > to within> several orders of magnitude of Modula-3's performance and satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >This sounds very much how Windows has been but finally changed. > > > => >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=> >); } /* access violation, reading from address 1 */ > > else catch (...) { => >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) => >catches all C++ exceptions but not these "Win32 structured exceptions". > >=> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more => >common case, and if you catch such an exception, you have to wonder, uh, so=> >me data is corrupt..which data? What can I possily do at this point, given => >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n adequate job of noticing things as soon as they have gone bad, and not at=> > an indeterminate point afterward, that sounds more viable. I suspect this => >might be the cas> >e, as long as you haven't called out to some buggy C cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.
> >Yes the odds of me confusing checked and unchecked errors are real. I think=> > I might have speculated as to the way things really are, while talking mai=> >nly about how things perhaps are not.
> > 
> >However..I still believe the implementation is the interface.
> >I don't see how Modula-3 fixes that.
> > 
> >> If you use the garbage collector alluded to by Knuth, timing changes >R>> in your program CANNOT cause it to run out of memory.

> >I didn't mean to necessarily link these things together.
> >Let's say garbage is collected immedately upon it being created.
> >A program still has a certain amount of non-garbage memory allocated at any=> > one time, and that amount might grow or shrink as changes are made to the => >code.
> > 
> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace it with a fixed sized array. Boom, I break anyone using large data. => >Now, granted, this is a dumb, backwards example. But it is an implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.
> > 
> > > If you use the Extended Static Checker (coded by some of the sam=> >e people
 > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown

> >Well...I'm ignorant of this particular checker. I am familiar with some of => >the static checking that is ot there. Only recently have I seen any static => >checking for race conditions. This is against and C and C++ code, mind you.=> > Perhaps they "resisted" static analysis until recently, hard to parse and => >all that.. Anyway, while I am not an expert on static checking potential an=> >d practise, I have seen just an astounding number of "crazy" bugs and I don=> >'t see much hope for much automatic bug detection. Most of the "bugs" found=> > by static checking are very basic things, like leaks or forgetting to chec=> >k an error, and never something particularly high level as to what the code=> > is actually supposed to do. I mean..I'm not sure this is a valid example o=> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=> > a terrible typist and I implement Plus with - and Minus with +. What stati=> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=> > testing will catch it. But I think the point is valid -- static checking n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t you can do is along the lines of m3-sys/tests -- a small "framework" for => >"running stuff" and "comparing the output against expected", perhaps being => >amitious and including "negative tests" (make sure erroneous source code fa=> >ils to compile and gives a good error message).
> > 
> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady well tested and known to work fairly well. However, this is just..like=> >..a fractal. Those available parts are built up out of yet again smaller we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which => >are really nothing special -- just another bunch of libraries) have bugs. "=> >There are bugs everywhere". "More code =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.
> > 
> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)
> > 
> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.
> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.
> > 
> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.
> > 
> >Ok, I'm repeating myself now, sorry.
> > 
> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=> > some problems. It doesn't do the impossible.
> > 
> >Have you used the NT386 system btw? One of the great things about Modula-3 => >is only parsing the headers once, and a resulting very fast compiler. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.
> > 
> >Gotta go,
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] Do I remember well...
> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800
> From: mika at async.caltech.edu
>
> Jay,
=> >>
> Sometimes I wonder if you have never read the Green Book!!! >R>>
> The very first section of the Modula-3 definition, Section => >2.1 of
> the Green Book, talks about the distinction between "checked=> > runtime
> errors" and "unchecked runtime errors" and ends with the s=> >entence
> "Unchecked runtime errors can occur only in unsafe modules.=> >"
>
> If I may make one of those philosophical diversions that=> > so often
> lead to Language Wars (but in this case isn't intended to=> >), you
> mentioned something a while back along the lines of (I am no=> >t quoting
> you verbatim) "every line of code is part of an applicati=> >on's
> interface, because it can cause...a change in memory usage or => >expose
> a previously unknown race condition"..
>
> The => >whole point of Modula-3 is that Modula-3 is part of a family
> of too=> >ls, a way of thinking, even, under which this isn't true.
>
> => >If you use the garbage collector alluded to by Knuth, timing changes
>=> >; in your program CANNOT cause it to run out of memory.
>
> If=> > you use the Extended Static Checker (coded by some of the same people
&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> >
> race conditions because there ARE no race conditions in your progr=> >am!
>
> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the
> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that
> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked
> runtime errors!
>
> Now it is tr=> >ue that we live in an imperfect world, and that neither
> any mortal => >nor any product of any mortal is perfect, but the WHOLE
> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of
> perfection!!!! All=> > of its users are longing to one day be programming
> in the Elysian => >Fields where there are no race conditions, heap
> overflows due to la=> >zy garbage collectors, nor any unchecked runtime
> errors. Will we ev=> >er get there? I don't know. But for me at
> least, one of the reasons=> > I use Modula-3 is because it tries, and
> I can see how one might fi=> >ll in the gaps and get it all the way.
> I know of no other programmi=> >ng environment that comes to within
> several orders of magnitude of => >Modula-3's performance and satisfies
> the same properties.
> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> >
> Implementations generally don't, as far as I know.
>
>=> >; The specification is really only fifty pages long...
>
> Mik=> >a
>
> Jay wrote:
> >This sounds very much how Windows=> > has been but finally changed.
> >
> > It used to be in=> > C++ you could do:
> >
> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */
> > else ca=> >tch (...) { printf("caught exception\n"); }
> >
> > now=> > you can't.
> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions".
> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software.
&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.
> > They can be raised by code via RaiseExc=> >eption though.
> >
> > There is a similar syntax for cat=> >ching them -- __try / __except.
> >
> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?
> >=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:
> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare.
> > (Even if C++ exceptions are implement=> >ed via RaiseException.)
> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix)
> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat
> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.
> >
> >If Modula-3 does an adequate job of notic=> >ing things as soon as they have gone bad, and not at an indeterminate point=> > afterward, that sounds more viable. I suspect this might be the cas
>=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.
> >
> >What about integer overflow? => >I wonder. :)
> >
> > - Jay


Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => > >textlink_jan' target=3D'_new'>Play now!> >=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 19:53:58 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 18:53:58 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types. specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199*** Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 26 20:22:57 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 26 Feb 2008 11:22:57 -0800 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: Your message of "Tue, 26 Feb 2008 11:45:51 +0100." <20080226114551.2b0icwj0g4ocw4wg@mail.elegosoft.com> Message-ID: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Olaf Wagner writes: >Quoting Jay : > >> I know this area has been brewing under the surface a while. >> I'll bring it up. :) >> >> I assume texts are read only? > >Yes. > >> I know lots of systems have read only strings. >> There are pluses and minus to them. They can be single-instanced. >> Some systems with read only strings have another type, such as >> "StringBuilder" or "StringBuffer". >> So -- I don't have a specific question, but maybe a mutable string >> "class" aka "type" is needed?Not necessarily in the language but in >> m3core or libm3? >> Maybe it's already there? CharSeq.T? From jayk123 at hotmail.com Tue Feb 26 20:53:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 19:53:24 +0000 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: I haven't tested this but it looks very suspicious.. When targeting 64 bit targets, the compiler thinks [-1 .. 1] is empty. When compiling things like "compare" functions. I didn't debug it but just looked at the code. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.4 diff -r1.4 TInt.i3 26c26 < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; --- > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff}}; another fix might be: > MOne = Int{1, IBytes{16_ff}}; IBytes used to be 16 bit integers but now is 8 bit integers. PM3 has: Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; which seems adequate for what is likely going on in these parts. I believe ".." fills with zeros, not the previous value. Also, is this objectionable? RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v retrieving revision 1.2 diff -r1.2 TextLiteral.i3 15c15 < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; --- > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - 32; *) Maybe. The 32 bit compiler doesn't like such large types (that follow from the use of this). Maybe preferable to allow 32 bit hosted compiler to allow 64 bit sized types? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 18:53:58 +0000Subject: [M3devel] tangential 64 bit... alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 20:57:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 19:57:20 +0000 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Hm, I don't think that fixes it actually. I'll have to dig in later, if highlighting the problem doesn't make it obvious to others.. What was there didn't look right for 32 bits even, but probably is for some reason.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 19:53:24 +0000Subject: [M3devel] 64 bit fixes? I haven't tested this but it looks very suspicious.. When targeting 64 bit targets, the compiler thinks [-1 .. 1] is empty. When compiling things like "compare" functions. I didn't debug it but just looked at the code. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.4 diff -r1.4 TInt.i3 26c26 < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; --- > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff,16_ff}}; another fix might be: > MOne = Int{1, IBytes{16_ff}}; IBytes used to be 16 bit integers but now is 8 bit integers. PM3 has: Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; which seems adequate for what is likely going on in these parts. I believe ".." fills with zeros, not the previous value. Also, is this objectionable? RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v retrieving revision 1.2 diff -r1.2 TextLiteral.i3 15c15 < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; --- > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - 32; *) Maybe. The 32 bit compiler doesn't like such large types (that follow from the use of this). Maybe preferable to allow 32 bit hosted compiler to allow 64 bit sized types? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 18:53:58 +0000Subject: [M3devel] tangential 64 bit... alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 21:14:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 15:14:18 -0500 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64- bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: > alpha/osf doesn't work because basictypes/ctypes has a problem with > the 32bit or 64bit types. > specifically "unsigned long" is "empty" for some reason and many > errors cascade from that. > > if you change: > unsigned_int = [16_0 .. 16_ffffffff]; > to > unsigned_int = [16_0 .. 16_fffffffe]; > > you get: > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/TWord.m3", line 199 > *** > > Presumably fixing this first problem is the first step in any "real" > 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem > should just be fixed as a matter of course. > > I know this is the least of anyone's concerns.. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 21:16:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 15:16:47 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: ARRAY OF CHAR/WIDECHAR? These are available in the various Text implementations. For exampe, Text8.T.contents. One can freely mutate these at leisure and the higher-level text will appear to change! On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > Olaf Wagner writes: >> Quoting Jay : >> >>> I know this area has been brewing under the surface a while. >>> I'll bring it up. :) >>> >>> I assume texts are read only? >> >> Yes. >> >>> I know lots of systems have read only strings. >>> There are pluses and minus to them. They can be single-instanced. >>> Some systems with read only strings have another type, such as >>> "StringBuilder" or "StringBuffer". >>> So -- I don't have a specific question, but maybe a mutable string >>> "class" aka "type" is needed?Not necessarily in the language but in >>> m3core or libm3? >>> Maybe it's already there? > > CharSeq.T? From jayk123 at hotmail.com Tue Feb 26 21:34:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:34:51 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Tony..are you sure..I'm not sure what I said is true. It seems clear that the host integer size is well abstracted while interpreting target numbers. I am more certain that [-1 .. 1] is empty, and this is likely a problem in TInt.Subtract.. PROCEDURE Add (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); carry := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO carry := a.x[i] + b.x[i] + carry; r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign # b_sign) OR (a_sign = r_sign); END Add; PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); borrow := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO borrow := a.x[i] - b.x[i] - borrow; r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign = b_sign) OR (a_sign = r_sign); END Subtract; Is it not adequate to treat carry and borrow as one it, zero or non-zero? Thinking in decimal about addition -- 9 + 9 = 18. You can never overflow to 20, 30, 40, etc. For substraction 0 - 9 = -9, never -10 or lower. However "1" is a full decimal digit, not a bit. In this case, the digits are bytes. Aha, so maybe the problem is the "and"? Let's check pm3 and decm3 3.6 again.. No, pm3 has the and too.. hm. I have to refresh some of my bit twiddling algorithms.. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 15:14:18 -0500 Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64-bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 21:35:56 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:35:56 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: Is that legal or is that subverting things? It depends on the context? Can the pointers be to read only memory in the code? - Jay > From: hosking at cs.purdue.edu> To: mika at async.caltech.edu> Date: Tue, 26 Feb 2008 15:16:47 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays?> > ARRAY OF CHAR/WIDECHAR?> > These are available in the various Text implementations. For exampe, > Text8.T.contents. One can freely mutate these at leisure and the > higher-level text will appear to change!> > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote:> > > Olaf Wagner writes:> >> Quoting Jay :> >>> >>> I know this area has been brewing under the surface a while.> >>> I'll bring it up. :)> >>>> >>> I assume texts are read only?> >>> >> Yes.> >>> >>> I know lots of systems have read only strings.> >>> There are pluses and minus to them. They can be single-instanced.> >>> Some systems with read only strings have another type, such as> >>> "StringBuilder" or "StringBuffer".> >>> So -- I don't have a specific question, but maybe a mutable string> >>> "class" aka "type" is needed?Not necessarily in the language but in> >>> m3core or libm3?> >>> Maybe it's already there?> >> > CharSeq.T?> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 26 21:56:31 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 20:56:31 +0000 Subject: [M3devel] tangential 64 bit... In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: Well I was lazy and did some math in the debugger and indeed one bit of carry or overflow is adequate, for addition and subtraction. You can do better with multiplicatio..and division I'd have to think a lot more about. It is an odd inconsistency between the Add and Subtract code below though.. I guess the reason is that carry will be 0 or 1, but borrow will be 0 or -1 and you want to convert -1 to +1. As well, carry/borrow should be sign extended if you run out of bits, so the -1 is used. It probably could be: add: < r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); > carry := ORD (carry # 0); r.x[i] := carry; subtract: < r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1);> if borrow # 0 then r.x[i] := Mask; borrow := 1; end no major difference. ? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 20:34:51 +0000 Tony..are you sure..I'm not sure what I said is true.It seems clear that the host integer size is well abstracted while interpreting target numbers. I am more certain that [-1 .. 1] is empty, and this is likely a problem in TInt.Subtract.. PROCEDURE Add (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); carry := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO carry := a.x[i] + b.x[i] + carry; r.x[i] := And (carry, Mask); carry := RShift (carry, BITSIZE (IByte)); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign # b_sign) OR (a_sign = r_sign); END Add; PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int): BOOLEAN = (* It is safe for r to alias a or b *) VAR n := MIN (a.n, b.n); borrow := 0; r_sign := Sign.Bad; a_sign := CheckSign (a, n); b_sign := CheckSign (b, n); BEGIN IF a_sign = Sign.Bad THEN RETURN FALSE END; IF b_sign = Sign.Bad THEN RETURN FALSE END; r.n := n; FOR i := 0 TO n-1 DO borrow := a.x[i] - b.x[i] - borrow; r.x[i] := And (borrow, Mask); borrow := And (RShift (borrow, BITSIZE (IByte)), 1); END; r_sign := CheckSign (r, n); <*ASSERT r_sign # Sign.Bad*> RETURN (a_sign = b_sign) OR (a_sign = r_sign); END Subtract;Is it not adequate to treat carry and borrow as one it, zero or non-zero?Thinking in decimal about addition -- 9 + 9 = 18.You can never overflow to 20, 30, 40, etc. For substraction 0 - 9 = -9, never -10 or lower. However "1" is a full decimal digit, not a bit.In this case, the digits are bytes. Aha, so maybe the problem is the "and"? Let's check pm3 and decm3 3.6 again..No, pm3 has the and too.. hm. I have to refresh some of my bit twiddling algorithms.. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] tangential 64 bit...Date: Tue, 26 Feb 2008 15:14:18 -0500 Indeed, on a 32-bit platform [16_0 .. 16_ffffffff] is an empty type, because 16_ffffffff is interpreted as an INTEGER constant with value -1, so the subrange is [0..-1]. This implies that one should not be using a 32-bit compiler to compile the 64-bit version of BasicCtypes.i3 in the first place. Of course, this also implies that one cannot directly cross-compile to 64-bit targets from 32-bit hosts, which is kind of broken. I suppose we could use LONGINT as necessary, realizing that LONGINT and INTEGER are distinct types that happen to have the same representation on 64-bit machines but different representation on 32-bit machines. Does anyone know if it was *ever* possible in the old PM3 to cross-compile from 32-bit to 64-bit? Presumably one needs an intermediate step where the C types used on the cross-compile host match those of the host instead of the target. On Feb 26, 2008, at 1:53 PM, Jay wrote: alpha/osf doesn't work because basictypes/ctypes has a problem with the 32bit or 64bit types.specifically "unsigned long" is "empty" for some reason and many errors cascade from that. if you change: unsigned_int = [16_0 .. 16_ffffffff];to unsigned_int = [16_0 .. 16_fffffffe]; you get: ****** runtime error:*** An array subscript was out of range.*** file "../src/TWord.m3", line 199***Presumably fixing this first problem is the first step in any "real" 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem should just be fixed as a matter of course. I know this is the least of anyone's concerns.. - Jay Connect and share in new ways with Windows Live. Get it now! Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Feb 26 22:01:22 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 26 Feb 2008 16:01:22 -0500 Subject: [M3devel] volume of cm3-related email traffic In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: <47C437CE.1E75.00D7.1@scires.com> I appreciate all the work everyone is doing these days on cm3, but I am having a problem I'd like to describe. I'm getting a large number of cm3-related email messages relayed to me each day. In many cases, I'm getting two copies of each message because folks are also addressing the message to me in addition to the m3devel list. The email address I've put on the m3devel and m3commit lists is my work email address. So, the large number of messages is now interfering with my job. In the past, this wasn't a problem because there weren't very many messages. I know I could change my email address for these mail lists to a private home mailbox, but I would not be able to check this box as frequently. Before I take this action, here are some suggestions I have: 1. Don't include the original sender on your reply; instead, just address to m3devel [I know I've been guilty about just lazily hitting the reply button without deleting the extra addresses, so this suggestion applies to me as well.] 2. Try not to use m3devel as a blog for a steady-stream of thought. Maybe we should setup a blog or something for this type of activity. 3. Try to think through and test your changes throughly to cut down on the number of commits. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Feb 26 22:28:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 26 Feb 2008 22:28:56 +0100 (CET) Subject: [M3devel] Is the climate right for a new promotion? In-Reply-To: <47C45BB4.40009@wichita.edu> References: <47C45BB4.40009@wichita.edu> Message-ID: On Tue, 26 Feb 2008, Rodney M. Bates wrote: > I have been thinking lately that the climate might be right for a new > attempt to promote Modula 3. I see two major trends and a small one > that suggest this. Promoting Modula-3 is always a good idea. But competition is hard. There are Ada and Eiffel which also follow the safety approach, but are still close to common imperative thinking. But also the Haskell community claims that it has the answer to safety issues and to parallelity. In functional programming you get more guarantees for free, but you have to pay with efficiency. However, there is constant progress in this respect. From my perspective, Modula-3's selling points against Ada and Eiffel are (relative) simplicity, and compared with functional programming Modula-3 may attract people by a conservative (imperative) programming style. From rcoleburn at scires.com Tue Feb 26 22:39:06 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 26 Feb 2008 16:39:06 -0500 Subject: [M3devel] CM3 package dependicies In-Reply-To: <1204020054.7354.2.camel@hias.m3w.org> References: <1204020054.7354.2.camel@hias.m3w.org> Message-ID: <47C440A7.1E75.00D7.1@scires.com> Yes, I too would like to know if this is solved. I had asked about this earlier when working on a nice way to keep the scripts up-to-date for rebuilding everything. Regards, Randy >>> Dragi?a Duri* 2/26/2008 5:00 AM >>> I am trying to figure out systematic way to map dependicies of packages so I can make nice hierarchy for RPM building... It's not too hard to map it out from m3makefiles, but it will be much better if someone already solved it :). Is there such a map already out there? TIA, dd -- Dragi?a Duri* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:10:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:10:30 -0500 Subject: [M3devel] 64 bit fixes? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> Message-ID: <3AC8BC28-2E71-4E46-8E4C-5E17266721E2@cs.purdue.edu> The constants MOne, etc are used explicitly with specific precision by the compiler front-end. These constants indicate that they have a certain number of significant bytes in their representation. If you truncate the 8 bytes to 4 bytes for 32-bit then we know that the value will still be correct. Making it length 1 breaks the use of the contants in both 32-bit and 64-bit representations. These changes were made when I put in the LONGINT support -- that's why they are different from PM3. On Feb 26, 2008, at 2:53 PM, Jay wrote: > I haven't tested this but it looks very suspicious.. > When targeting 64 bit targets, the compiler thinks [-1 .. 1] is > empty. > When compiling things like "compare" functions. > I didn't debug it but just looked at the code. > > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v > retrieving revision 1.4 > diff -r1.4 TInt.i3 > 26c26 > < MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}}; > --- > > MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff, > 16_ff,16_ff,16_ff,16_ff}}; > > > another fix might be: > > > > MOne = Int{1, IBytes{16_ff}}; > > IBytes used to be 16 bit integers but now is 8 bit integers. > PM3 has: > > Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}}; > One = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}}; > MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}}; > > which seems adequate for what is likely going on in these parts. > > I believe ".." fills with zeros, not the previous value. > > Also, is this objectionable? > > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v > retrieving revision 1.2 > diff -r1.2 TextLiteral.i3 > 15c15 > < MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32; > --- > > MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) - > 32; *) > > Maybe. The 32 bit compiler doesn't like such large types (that > follow from the use of this). > Maybe preferable to allow 32 bit hosted compiler to allow 64 bit > sized types? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Tue, 26 Feb 2008 18:53:58 +0000 > Subject: [M3devel] tangential 64 bit... > > alpha/osf doesn't work because basictypes/ctypes has a problem with > the 32bit or 64bit types. > specifically "unsigned long" is "empty" for some reason and many > errors cascade from that. > > if you change: > unsigned_int = [16_0 .. 16_ffffffff]; > to > unsigned_int = [16_0 .. 16_fffffffe]; > > you get: > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/TWord.m3", line 199 > *** > > Presumably fixing this first problem is the first step in any "real" > 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem > should just be fixed as a matter of course. > > I know this is the least of anyone's concerns.. > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:14:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:14:37 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: <1C38F3E3-1E39-459D-879D-118C9D871E55@cs.purdue.edu> Legal depends on context, as you note. If you are able to see the representation of a given text then you can mess with it accordingly. The pointers for these are not to readonly memory. Note that you probably will break things if you try to write to TextLiteral.T.buf, since that might be readonly. Here be dragons, but my point was that every text has an underlying representation that may or may not be sensibly mutable. I am a strong believer in TEXT being immutable in the general case. On Feb 26, 2008, at 3:35 PM, Jay wrote: > Is that legal or is that subverting things? > It depends on the context? > Can the pointers be to read only memory in the code? > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: mika at async.caltech.edu > > Date: Tue, 26 Feb 2008 15:16:47 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] text inefficiency? good mutable string > type? arrays? > > > > ARRAY OF CHAR/WIDECHAR? > > > > These are available in the various Text implementations. For exampe, > > Text8.T.contents. One can freely mutate these at leisure and the > > higher-level text will appear to change! > > > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > > > > > Olaf Wagner writes: > > >> Quoting Jay : > > >> > > >>> I know this area has been brewing under the surface a while. > > >>> I'll bring it up. :) > > >>> > > >>> I assume texts are read only? > > >> > > >> Yes. > > >> > > >>> I know lots of systems have read only strings. > > >>> There are pluses and minus to them. They can be single- > instanced. > > >>> Some systems with read only strings have another type, such as > > >>> "StringBuilder" or "StringBuffer". > > >>> So -- I don't have a specific question, but maybe a mutable > string > > >>> "class" aka "type" is needed?Not necessarily in the language > but in > > >>> m3core or libm3? > > >>> Maybe it's already there? > > > > > > CharSeq.T? > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:18:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:18:24 -0500 Subject: [M3devel] volume of cm3-related email traffic In-Reply-To: <47C437CE.1E75.00D7.1@scires.com> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <20080226113607.lo4wz7yio00cw8wo@mail.elegosoft.com> <47C437CE.1E75.00D7.1@scires.com> Message-ID: Sounds like good practice to me! [Note that I am replying only to m3devel. :-) ] On Feb 26, 2008, at 4:01 PM, Randy Coleburn wrote: > I appreciate all the work everyone is doing these days on cm3, but I > am having a problem I'd like to describe. > I'm getting a large number of cm3-related email messages relayed to > me each day. In many cases, I'm getting two copies of each message > because folks are also addressing the message to me in addition to > the m3devel list. > > The email address I've put on the m3devel and m3commit lists is my > work email address. So, the large number of messages is now > interfering with my job. In the past, this wasn't a problem because > there weren't very many messages. > > I know I could change my email address for these mail lists to a > private home mailbox, but I would not be able to check this box as > frequently. Before I take this action, here are some suggestions I > have: > > 1. Don't include the original sender on your reply; instead, just > address to m3devel > [I know I've been guilty about just lazily hitting the reply button > without deleting the extra addresses, so this suggestion applies to > me as well.] > > 2. Try not to use m3devel as a blog for a steady-stream of > thought. Maybe we should setup a blog or something for this type of > activity. > > 3. Try to think through and test your changes throughly to cut down > on the number of commits. > > Regards, > Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 26 23:43:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 17:43:17 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> Message-ID: <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> I suppose the question here is how often you exceed the 256-character stack-allocated buffer size? If not often then occasionally allocating in the heap is not a huge problem. I'm not too fussed about this anyway because generational GC will quickly reclaim things that die as young as this buffer does. I think you underestimate the effectiveness of modern GC algorithms. Anyway, optimizing here for short nm texts presumably handles the common case. Why work hard to optimize the uncommon case? On Feb 25, 2008, at 10:38 AM, Jay wrote: > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > Here is some apparently typical code: > > PROCEDURE Escape (nm: TEXT): TEXT = > VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (nm = NIL) THEN RETURN NIL; END; > len := Text.Length (nm); > IF (len + len <= NUMBER (buf)) > THEN RETURN DoEscape (nm, len, buf); > ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + > len)^); > END; > END Escape; > > PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF > CHAR): TEXT = > VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; > BEGIN > Text.SetChars (buf, nm); > FOR i := 0 TO len-1 DO > IF (buf[i] = BackSlash) THEN INC (n_escapes); END; > END; > IF (n_escapes = 0) THEN RETURN nm; END; > src := len - 1; > dest := src + n_escapes; > WHILE (src > 0) DO > c := buf[src]; DEC (src); > buf[dest] := c; DEC (dest); > IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); > END; > END; > RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); > END DoEscape; > > > Look at how inefficient this is. > For a long string it makes a heap allocation, even if in the end it > makes no changes to the string. > For any length string it copies it out to an array. > Then if there are any changes, it copies it again, probably into > heap, likely the input immediately becoming garbage. > Heap allocation may be fast, but building up garbage and causing > more work for the garbage collector I assume is bad. > And if the string had no backslashes, it's all a big waste. > > I assume texts are read only? > > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > > > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed? > Not necessarily in the language but in m3core or libm3? > Maybe it's already there? > > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a > good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => > wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not > characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Feb 27 00:14:31 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 26 Feb 2008 17:14:31 -0600 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> Message-ID: <47C49D57.4090600@wichita.edu> Mutating the Text implementations certainly could subvert the expected semantics of TEXT, for other TEXT values you might not expect to have any relation to what you are doing. But in my view, the much more important point is that ARRAY OF CHAR/ WIDECHAR, where you create your own values, are the mutable strings in Modula-3. You can pretty much do anything you want with this, including writing your own string abstraction, with different internal representation. In fact, I have done so, highly tailored to an application with specific, known performance characteristics and usage patterns. Jay wrote: > Is that legal or is that subverting things? > It depends on the context? > Can the pointers be to read only memory in the code? > > - Jay > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > To: mika at async.caltech.edu > > Date: Tue, 26 Feb 2008 15:16:47 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] text inefficiency? good mutable string type? > arrays? > > > > ARRAY OF CHAR/WIDECHAR? > > > > These are available in the various Text implementations. For exampe, > > Text8.T.contents. One can freely mutate these at leisure and the > > higher-level text will appear to change! > > > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote: > > > > > Olaf Wagner writes: > > >> Quoting Jay : > > >> > > >>> I know this area has been brewing under the surface a while. > > >>> I'll bring it up. :) > > >>> > > >>> I assume texts are read only? > > >> > > >> Yes. > > >> > > >>> I know lots of systems have read only strings. > > >>> There are pluses and minus to them. They can be single-instanced. > > >>> Some systems with read only strings have another type, such as > > >>> "StringBuilder" or "StringBuffer". > > >>> So -- I don't have a specific question, but maybe a mutable string > > >>> "class" aka "type" is needed?Not necessarily in the language but in > > >>> m3core or libm3? > > >>> Maybe it's already there? > > > > > > CharSeq.T? > > > > > ------------------------------------------------------------------------ > Climb to the top of the charts! Play the word scramble challenge with > star power. Play now! > -- ------------------------------------------------------------- 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 Wed Feb 27 00:46:26 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 23:46:26 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> Message-ID: Tony, what about the need to copy? The inability to iterate through characters without a function call per character? I guess though, from what you pointed out, a read only direct pointer is viable. And that removes the 256 character stack usage -- which is a bit piggy as it is. So then..I guess the next step in some compromise here is that it should perhaps be viable to get a read only pointer to a string (maybe already the case), compute the required size of the new one (follows naturally), and then be able to split up allocation and filling in of a string, a function to allocate and get a direct pointer, then fill in your data, then "seal" the text making it read only. And I guess really you can just carefully use the "subversive" method here -- up to you to not pass the "unsealed" text off to anyone else until you are done writing to it. Then just to deal with the varying representation but as I was suggesting, maybe that can be forced somehow. Maybe creation can specify an encoding, or the "get buffer" function could -- though ideally there is just one, not two. The stack vs. heap behavior is also not ideal in that it's nice for the performance of something to scale linearly with input, not suddenly slow way down when data exceeds some arbitrary threshold. Granted, a lot of code just starts failing, so merely slowing down is "progress". As well, eventually you end up swapping to disk, if you don't first run out of address space, so there will be limits at which things slow down or fail, just that they ought to be fairly large. I also rather hoped/assumed that compile time text constants were formed constant-ly by the compiler, that the compiler knows their runtime layout. I realize the division of labor between compiler and runtime can be made at varying points, with varying resulting flexibility, but also varying resulting efficiency. - Jay From: hosking at cs.purdue.eduTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 17:43:17 -0500Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays? I suppose the question here is how often you exceed the 256-character stack-allocated buffer size? If not often then occasionally allocating in the heap is not a huge problem. I'm not too fussed about this anyway because generational GC will quickly reclaim things that die as young as this buffer does. I think you underestimate the effectiveness of modern GC algorithms. Anyway, optimizing here for short nm texts presumably handles the common case. Why work hard to optimize the uncommon case? On Feb 25, 2008, at 10:38 AM, Jay wrote: I know this area has been brewing under the surface a while.I'll bring it up. :) Here is some apparently typical code: PROCEDURE Escape (nm: TEXT): TEXT = VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; BEGIN IF (nm = NIL) THEN RETURN NIL; END; len := Text.Length (nm); IF (len + len <= NUMBER (buf)) THEN RETURN DoEscape (nm, len, buf); ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + len)^); END; END Escape;PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF CHAR): TEXT = VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; BEGIN Text.SetChars (buf, nm); FOR i := 0 TO len-1 DO IF (buf[i] = BackSlash) THEN INC (n_escapes); END; END; IF (n_escapes = 0) THEN RETURN nm; END; src := len - 1; dest := src + n_escapes; WHILE (src > 0) DO c := buf[src]; DEC (src); buf[dest] := c; DEC (dest); IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); END; END; RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); END DoEscape;Look at how inefficient this is.For a long string it makes a heap allocation, even if in the end it makes no changes to the string.For any length string it copies it out to an array.Then if there are any changes, it copies it again, probably into heap, likely the input immediately becoming garbage.Heap allocation may be fast, but building up garbage and causing more work for the garbage collector I assume is bad.And if the string had no backslashes, it's all a big waste. I assume texts are read only? I know lots of systems have read only strings.There are pluses and minus to them. They can be single-instanced.Some systems with read only strings have another type, such as "StringBuilder" or "StringBuffer".So -- I don't have a specific question, but maybe a mutable string "class" aka "type" is needed?Not necessarily in the language but in m3core or libm3?Maybe it's already there? I just spent a few hours diddling with arrays of chars.Unfortunately they are not resizable.It was not entirely satisfactory. Besides the array I had to pass around a length and a start.Wrapping this up in one record TYPE MutableString= ... might be a good idea. For more efficient read only access, would it be reasonable for the runtime to materialize on-demand 8 bit and 16 bit representations of a string if a user calls some new thing like Text.GetDirectA (t: TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF WIDECHAR? Throw an exception if the string cannot be represented with 8 bit characters? Or use utf8? Besides, I know I'm a big predictable whiner but I like how this works in Windows..It may not have been as seamless, but it works and it really doesn't tend to break or slow down existing code.roughly: "foo" is an 8 bit string of type char* (or const char* or possibly const char[4]) L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) "L" for "long" aka "wide" Functions must be written to specifically use one or the other.In C++ you can templatize. There is std::string and std::wstring that are template instantiations.Lots of C functions are duplicated. strcpy => wcscpy, strcat => wcscat, etc.And really there's no point in 8 bit strings.If you have a blob, that's an array of bytes or something, not characters. It works. Utf8 is another seemingly popular route but I think it's a hack.I think mostly people don't touch their code and say, voila, it's utf8, and they only really support the same old English or possibly 8 bit characters (some European characters).Granted, to some extent, this does work, as long as you don't do anything with the string but strlen, strcpy, and some others and pass it to code that does treat it correctly. Still, variably sized encodings seem like a bad idea here, and 16 bits per character seem affordable enough. And yes, I know that Unicode is actually know 20 bits per character and some characters take two wchar_ts but I try to ignore that...And I know there is a lot of existing code, but sometimes there is a need for progress too... Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 27 00:57:59 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 26 Feb 2008 23:57:59 +0000 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: <47C49D57.4090600@wichita.edu> References: <200802261922.m1QJMvXb052910@camembert.async.caltech.edu> <47C49D57.4090600@wichita.edu> Message-ID: Right that arrays of chars/widechars make good strings, however you run into the problem of what is the ubiquitous type that is good to have around because any other code can deal with it. It's often nice to have fewer types and therefore more easier interoperability among code -- avoid any thick translation layer or conversion of data back and forth. It's tough though of course, since not one size (type) fits all. It seems annoying and wasteful, but also plain ok, for everyone to have their own string, array, list, etc. types. My "crazy" view though is that it is better to have one string class per programmer than any programmer with no string type to use. Fewer types/libraries would be preferable, but the alternative of anyone having none is worse. It is easy enough to write these things for yourself if there really is no acceptable existing option. (though the ease with which folks dismiss existing alternatives is also bad) Some people claim they need to leave the writing of string/array/list to the super-skilled library developers, but I don't think so. The line between library producer and library consumer is not always so clear. I may not be capable of whipping together a windowing system or a threading library or compiler, but string and growable array are plenty easy enough. :) Sometimes the library writers aren't even so good.. I remember reading, if I interpreted it correctly, how the Python developers were so proud of their growable arrays that are so efficient because they grow in chunks of constant size larger than 1...except that's not actually how you write an efficient growable array, you have to grow exponentially -- by a factor greater than 1, such as 2 or 3 or 1.5. This is for the scenario of folks adding one element at a time. I also found Modula-3 arrays to be a little disappointing so far. Could be me at this point. I'd like to be able to change their length and possibly remove elements from the start without a copy. I suppose that involves a dreaded "interior pointer" and gc problems. I know SOME about SUBARRAYS but so far, it seems SUBARRAY can only be passed as parameters or use in "surprisingly powerful" assignment: subarray(a, offset, length) := subarray(b, offset, length). It seems I cannot assign, like, a subarray to a reference. a: array [0..9] of integer, b : ref array [8..9] of integer := subarray(a, 8) ? I'll have to look into that too.. Really I was going to try to shut up today at Randy's request but folks responded.. :) - Jay > Date: Tue, 26 Feb 2008 17:14:31 -0600> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] text inefficiency? good mutable string type? arrays?> > Mutating the Text implementations certainly could subvert the expected> semantics of TEXT, for other TEXT values you might not expect to have> any relation to what you are doing.> > But in my view, the much more important point is that ARRAY OF CHAR/> WIDECHAR, where you create your own values, are the mutable strings> in Modula-3. You can pretty much do anything you want with this,> including writing your own string abstraction, with different internal> representation. In fact, I have done so, highly tailored to an> application with specific, known performance characteristics and> usage patterns.> > Jay wrote:> > Is that legal or is that subverting things?> > It depends on the context?> > Can the pointers be to read only memory in the code?> > > > - Jay> > > > > > ------------------------------------------------------------------------> > > > > From: hosking at cs.purdue.edu> > > To: mika at async.caltech.edu> > > Date: Tue, 26 Feb 2008 15:16:47 -0500> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] text inefficiency? good mutable string type? > > arrays?> > >> > > ARRAY OF CHAR/WIDECHAR?> > >> > > These are available in the various Text implementations. For exampe,> > > Text8.T.contents. One can freely mutate these at leisure and the> > > higher-level text will appear to change!> > >> > > On Feb 26, 2008, at 2:22 PM, Mika Nystrom wrote:> > >> > > > Olaf Wagner writes:> > > >> Quoting Jay :> > > >>> > > >>> I know this area has been brewing under the surface a while.> > > >>> I'll bring it up. :)> > > >>>> > > >>> I assume texts are read only?> > > >>> > > >> Yes.> > > >>> > > >>> I know lots of systems have read only strings.> > > >>> There are pluses and minus to them. They can be single-instanced.> > > >>> Some systems with read only strings have another type, such as> > > >>> "StringBuilder" or "StringBuffer".> > > >>> So -- I don't have a specific question, but maybe a mutable string> > > >>> "class" aka "type" is needed?Not necessarily in the language but in> > > >>> m3core or libm3?> > > >>> Maybe it's already there?> > > >> > > > CharSeq.T?> > >> > > > > > ------------------------------------------------------------------------> > Climb to the top of the charts! Play the word scramble challenge with > > star power. Play now! > > > > -- > -------------------------------------------------------------> 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 _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Feb 27 10:41:10 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 Feb 2008 10:41:10 +0100 Subject: [M3devel] bootstrap from IL code? Message-ID: <1204105270.13580.10.camel@hias.m3w.org> If I remember correctly (fog of advanced age and all:), we used to have bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did not depend on installed Modula-3 compiler. Are there some scripts to make such bootstrap archive now? So we can make self-buildable package without Modula-3 compiler packaged in. dd -- Dragi?a Duri? From dragisha at m3w.org Wed Feb 27 10:57:35 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 27 Feb 2008 10:57:35 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204105270.13580.10.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> Message-ID: <1204106255.13580.13.camel@hias.m3w.org> I see where it is... But, somebody probably already did it... Is there short script or howto on making cm3-min substitute based on IL? And why we don't have cm3-min-*-*... buildable with only gcc on-system?? IMO, this would help anybody building system. dd On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote: > If I remember correctly (fog of advanced age and all:), we used to have > bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did > not depend on installed Modula-3 compiler. > > Are there some scripts to make such bootstrap archive now? So we can > make self-buildable package without Modula-3 compiler packaged in. > > dd > -- Dragi?a Duri? From wagner at elegosoft.com Wed Feb 27 11:35:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 11:35:03 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204106255.13580.13.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> Message-ID: <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Quoting Dragi?a Duri? : > I see where it is... But, somebody probably already did it... Is there > short script or howto on making cm3-min substitute based on IL? > > And why we don't have cm3-min-*-*... buildable with only gcc on-system?? > IMO, this would help anybody building system. This was in PM3, but has never been integrated into CM3. If you'd like to work on it, it will be great. We could even come to the point were we build distributions for most targets on one platforms (possibly with the exception of crossing 32->64 bit boundaries). When extending the existing scripts, please make sure that the existing interfaces and functions keep working. Olaf > dd > > On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote: >> If I remember correctly (fog of advanced age and all:), we used to have >> bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did >> not depend on installed Modula-3 compiler. >> >> Are there some scripts to make such bootstrap archive now? So we can >> make self-buildable package without Modula-3 compiler packaged in. >> >> dd -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 27 11:54:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 10:54:41 +0000 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Message-ID: DEC M3.6 was distributed as assembly and some C files. It could just as well be .obj files. Most of the C was the implementation of quake, but maybe also dtoa.c, hand.c, and such. There is already a lot here, there is something like having the build stop either right before running as or right before ld, and then somehow resuming after all the files are copied to the target. I thought Olaf would answer "more positively", and I thought the stuff in scripts/* does about what you want, and I believe there is good documentation on exactly this. I realize that in what I said there, there's a mystery as to how to "resume" on the target. Cm3 could about some big .sh or .cmd file easily enough. Maybe the difference is just the amount of "friendliness" of the process? Not easy enough for "beginners"? I really expect we'll, um, "cross" the 32/64 boundary relatively soon in terms of, um, cross building. Unless I'm badly mistaken as to the general design of cm3. It sure looks prepared to do correct compile time math how the target would. And heck, maybe it could just skip constant propagation if not? (gcc also uses a lib in to do correct floating point target math, one of the dependencies I was initially missing, ./configure complains clearly) Not sure, it might be matters of correctness and not just optimization that require target math. For array maximum sizes, if that was the only problem, probably reasonable to just have 32 bit limits (TextLiteral.i3 has a problem building because of this.) I need to try out NT386GNU's GUI stuff (X Windows), make sure all of "std" can build and run for some reasonably large set (a lot already builds), and fix the Windows bitmap problem, and maybe PPC_LINUX dynamic linking and get a current distribution out, but I think getting ALPHA_OSF to compile (but not assemble or link) is among the next good things to try, as a stepping stone to a "real" 64 bit target such as, as I said, AMD64, IA64, POWER64, SPARC64. AMD64 of course I think is the most interesting, the cheapest hardware and it runs "everything" -- Windows, Linux, I think Solaris -- and in all cases "both" architectures even, via multi boot and always/sometimes "one boot". (I know this is true of Windows, I believe it is optional on Linux depending on distribution/configuration, they call it "biarch", and unsure about Solaris, not sure it has an AMD64 port or not, but certainly it has x86.) IF IF IF I'm right as to how the compiler works, this really shouldn't be a big deal.. We'll see.. - Jay > Date: Wed, 27 Feb 2008 11:35:03 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] bootstrap from IL code?> > Quoting Dragi?a Duri? :> > > I see where it is... But, somebody probably already did it... Is there> > short script or howto on making cm3-min substitute based on IL?> >> > And why we don't have cm3-min-*-*... buildable with only gcc on-system??> > IMO, this would help anybody building system.> > This was in PM3, but has never been integrated into CM3. If you'd> like to work on it, it will be great. We could even come to the point> were we build distributions for most targets on one platforms (possibly> with the exception of crossing 32->64 bit boundaries).> > When extending the existing scripts, please make sure that the existing> interfaces and functions keep working.> > Olaf> > > dd> >> > On Wed, 2008-02-27 at 10:41 +0100, Dragi?a Duri? wrote:> >> If I remember correctly (fog of advanced age and all:), we used to have> >> bootstrap archives for SRC Modula-3 (and maybe also for PM3) which did> >> not depend on installed Modula-3 compiler.> >>> >> Are there some scripts to make such bootstrap archive now? So we can> >> make self-buildable package without Modula-3 compiler packaged in.> >>> >> dd> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 27 14:43:12 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 14:43:12 +0100 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <1204112891.13580.27.camel@hias.m3w.org> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> Message-ID: <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Quoting Dragi?a Duri? : > On Wed, 2008-02-27 at 11:35 +0100, Olaf Wagner wrote: >> Quoting Dragi?a Duri? : >> >> > I see where it is... But, somebody probably already did it... Is there >> > short script or howto on making cm3-min substitute based on IL? >> > >> > And why we don't have cm3-min-*-*... buildable with only gcc on-system?? >> > IMO, this would help anybody building system. >> >> This was in PM3, but has never been integrated into CM3. If you'd >> like to work on it, it will be great. We could even come to the point >> were we build distributions for most targets on one platforms (possibly >> with the exception of crossing 32->64 bit boundaries). > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had problems > cross compiling on 32bit for 64bit... I've made some quick&dirty fix so > it was IL code being archived/transferred/compiled, and not assembly as > was usual at time... John Polstra extended and integrated that trick > into building system of PM3, I don't know where that code is now. > Anybody? It should be in the PM3 repository, which is hosted and available at the elego WWW servers, too: http://modula3.elegosoft.com/pm3/ There hasn't been much activity in recent years though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Feb 27 15:41:02 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 27 Feb 2008 09:41:02 -0500 Subject: [M3devel] bootstrap from IL code? In-Reply-To: References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> Message-ID: Take a look at the code in pm3/language/modula3/m3compiler/ m3bootstrap: this would build a bunch of assembler files and a Makefile for bootstrapping without the M3 compiler. On Feb 27, 2008, at 5:54 AM, Jay wrote: > DEC M3.6 was distributed as assembly and some C files. It could just > as well be .obj files. > Most of the C was the implementation of quake, but maybe also > dtoa.c, hand.c, and such. > There is already a lot here, there is something like having the > build stop either right before running as or right before ld, and > then somehow resuming after all the files are copied to the target. > I thought Olaf would answer "more positively", and I thought the > stuff in scripts/* does about what you want, and I believe there is > good documentation on exactly this. I realize that in what I said > there, there's a mystery as to how to "resume" on the target. Cm3 > could about some big .sh or .cmd file easily enough. > Maybe the difference is just the amount of "friendliness" of the > process? Not easy enough for "beginners"? > > > I really expect we'll, um, "cross" the 32/64 boundary relatively > soon in terms of, um, cross building. > Unless I'm badly mistaken as to the general design of cm3. > It sure looks prepared to do correct compile time math how the > target would -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 27 21:02:00 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 20:02:00 +0000 Subject: [M3devel] bootstrap from IL code? In-Reply-To: <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Message-ID: > Date: Feb 2008 > Quoting Dragi?a Duri? : > > >> were we build distributions for most targets on one platforms (possibly > >> with the exception of crossing 32->64 bit boundaries). > > > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had problems > > cross compiling on 32bit for 64bit... I've made some quick&dirty fix so These problems have all been fixed in gcc by now, right? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your HotmailR-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 27 21:30:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 27 Feb 2008 15:30:26 -0500 Subject: [M3devel] bootstrap from IL code? In-Reply-To: References: <1204105270.13580.10.camel@hias.m3w.org> <1204106255.13580.13.camel@hias.m3w.org> <20080227113503.2xrc6f7cgswcoow8@mail.elegosoft.com> <1204112891.13580.27.camel@hias.m3w.org> <20080227144312.tnqb77nracogs4o8@mail.elegosoft.com> Message-ID: <3F1B6366-DA7A-42A8-B8CB-545B76E6D9AE@cs.purdue.edu> Should be fixed, yes. On Feb 27, 2008, at 3:02 PM, Jay wrote: > > Date: Feb 2008 > > Quoting Dragi?a Duri? : > > > > >> were we build distributions for most targets on one platforms > (possibly > > >> with the exception of crossing 32->64 bit boundaries). > > > > > > When I ported PM3 to LINUXALPHA, problem was in gcc, it had > problems > > > cross compiling on 32bit for 64bit... I've made some > quick&dirty fix so > > > These problems have all been fixed in gcc by now, right? > > > - Jay > > Need to know the score, the latest news, or you need your HotmailR- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 27 22:23:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 27 Feb 2008 22:23:05 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: <47C440A7.1E75.00D7.1@scires.com> References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> Message-ID: <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Quoting Randy Coleburn : > Yes, I too would like to know if this is solved. > I had asked about this earlier when working on a nice way to keep the > scripts up-to-date for rebuilding everything. > Regards, > Randy Perhaps I misunderstood what you were asking for; I've checked-in a package dependency list in scripts/cm3-pkg-deps now. The actual package paths relative to ROOT can be found in scripts/PKGS. A list of all packages is kept in scripts/pkginfo.txt. Let's see if this is useful. I'll add the program to extract the dependencies soon. Olaf >>>> Dragi?a Duri* 2/26/2008 5:00 AM >>> > I am trying to figure out systematic way to map dependicies of > packages > so I can make nice hierarchy for RPM building... It's not too hard to > map it out from m3makefiles, but it will be much better if someone > already solved it :). Is there such a map already out there? > > TIA, > dd > -- > Dragi?a Duri* > > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Feb 27 22:32:22 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 27 Feb 2008 21:32:22 +0000 Subject: [M3devel] CM3 package dependicies In-Reply-To: <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Message-ID: > A list of all packages is kept in scripts/pkginfo.txt. I also plan to make scripts/python and scripts/win use pkginfo.txt, esp. scripts/python. If anyone cares, please speak up. I would also like filtering to be driven by pkginfo.txt, however that seems of quite low importance, esp. in ratio to how obvious the design is (not entirely obvious, like if something really really simple will suffice or be too ambiguous). Also, Olaf, about two months ago I believe you said "std should be all". I hesitated. "Are you certain?" I kind of also think filtering needs a command line override. Maybe just that do-pkg should do no filtering? You know, I always set OMIT_GCC and I occasionally want to build m3cc. I do like how sh can set env vars on the command line for just that invocation, but I'm not willing to switch to sh just for that feature with all that I'd lose. Again, though, I've settled into the larger consensus that this stuff doesn't matter too much. :) - Jay > Date: Wed, 27 Feb 2008 22:23:05 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] CM3 package dependicies> > Quoting Randy Coleburn :> > > Yes, I too would like to know if this is solved.> > I had asked about this earlier when working on a nice way to keep the> > scripts up-to-date for rebuilding everything.> > Regards,> > Randy> > Perhaps I misunderstood what you were asking for; I've checked-in> a package dependency list in scripts/cm3-pkg-deps now. The actual> package paths relative to ROOT can be found in scripts/PKGS.> A list of all packages is kept in scripts/pkginfo.txt.> > Let's see if this is useful.> > I'll add the program to extract the dependencies soon.> > Olaf> > >>>> Dragi?a Duri* 2/26/2008 5:00 AM >>>> > I am trying to figure out systematic way to map dependicies of> > packages> > so I can make nice hierarchy for RPM building... It's not too hard to> > map it out from m3makefiles, but it will be much better if someone> > already solved it :). Is there such a map already out there?> >> > TIA,> > dd> > --> > Dragi?a Duri* > >> >> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 00:14:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 00:14:49 +0100 Subject: [M3devel] CM3 package dependicies In-Reply-To: References: <1204020054.7354.2.camel@hias.m3w.org> <47C440A7.1E75.00D7.1@scires.com> <20080227222305.t01266yn4kgwgks4@mail.elegosoft.com> Message-ID: <20080228001449.v1fpl1gwg0c8gwcg@mail.elegosoft.com> Quoting Jay : >> A list of all packages is kept in scripts/pkginfo.txt. > I also plan to make scripts/python and scripts/win use pkginfo.txt, > esp. scripts/python. > If anyone cares, please speak up. > I would also like filtering to be driven by pkginfo.txt, however > that seems of quite low importance, esp. in ratio to how obvious the > design is (not entirely obvious, like if something really really > simple will suffice or be too ambiguous). > > Also, Olaf, about two months ago I believe you said "std should be all". > I hesitated. "Are you certain?" Seems I was wrong there. When we first made the system run again, we thought of `std' to be the compilable and usable packages. Now all packages should at least compile. Perhaps we should drop it or define a more sensible set of `standard packages'? > I kind of also think filtering needs a command line override. > Maybe just that do-pkg should do no filtering? Sounds OK. Or add a -f option. > You know, I always set OMIT_GCC and I occasionally want to build m3cc. > I do like how sh can set env vars on the command line for just that > invocation, but I'm not willing to switch to sh just for that > feature with all that I'd lose. We'll get you around in the end. This is Unix. Resistance is futile :-) > Again, though, I've settled into the larger consensus that this > stuff doesn't matter too much. :) Right :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 28 09:31:32 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:31:32 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 09:44:11 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:44:11 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 09:59:47 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 08:59:47 +0000 Subject: [M3devel] FW: put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000 pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 10:25:45 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 09:25:45 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <20080228082322.3662910D46B6@birch.elegosoft.com> References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: Is it easy enough for the commit mails to contain links to view all of the diffs described?That's be super duper nice. I find browsing the cvsweb very inefficient. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:59:47 +0000 truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000 pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000 ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 10:33:15 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 10:33:15 +0100 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: <20080228103315.tkxlxp32144kgsk8@mail.elegosoft.com> Quoting Jay : > Is it easy enough for the commit mails to contain links to view all > of the diffs described?That's be super duper nice. I'd say that depends on somebody providing the appropriate patch for the CVS commit hook script on birch.elegosoft.com ;-) Olaf PS: You can view the diffs related to every commit via the tinderbox page in the `Guilty' column though. That's quite convenient. > I find browsing the cvsweb very inefficient. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 28 14:03:07 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 13:03:07 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: Done.On birch, time sh -c "./do-pkg.sh realclean libm3 && ./do-pkg.sh buildship libm3" seems go from about 35 seconds to about 15 seconds.Let me know what improvements people see? OMIT_GCC=yes do-cm3-std probably is the best test.alarmthreads platforms (PPC_LINUX), no change (still rebuilding actually). NT386GNU still seems just as slow. At some point I will try batching up the cm3cg and/or as calls. Maybe via a wrapper on Windows only that then just makes n Win32 CreateProcess calls instead of n Cygwin vforks. It might be nice to have Quake callouts for before_first_compile, after_last_compile, before_first_assemble, after_last_assemble, though this brings up that there should perhaps be begin_package/end_package, for cm3 to become a multi-package builder..and then, really, multi-threaded, so there'd have to be maybe extra state variables passed around, maybe. (and then Cygwin's waitpid not being threadsafe breaks this...) (For prototyping, before_first compile is implied, after_last_compile/assemble is implied by make_lib/skip_lib/link, so any queuing up could be flushed at that point. Goal here being not to reduce process creates, but cygwin processes created from cygwin processes. oh, and I just realized, cm3cg should probably mark all data as "no copy" when targeting Cygwin. That might help a bunch.) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Tue, 29 Jan 2008 08:08:38 -0500> To: mika at async.caltech.edu> > Indeed. We definitely need to fix this...> > > On Jan 29, 2008, at 5:45 AM, Mika Nystrom wrote:> > > Jay writes:> > ..> >> It is painfully noticable how much more slowly NT386GNU m3cc > >> builds than NT=> >> 386MINGNU m3cc, presumably due to the underlying slower bash/sed/ > >> make etc.> > ..> >> > are you sure it's not the Thread.Sleep(0.1d0) in Process.Wait?> >> > Mika> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 28 14:28:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 14:28:55 +0100 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Quoting Jay : > Done.On birch, time sh -c "./do-pkg.sh realclean libm3 && > ./do-pkg.sh buildship libm3" > seems go from about 35 seconds to about 15 seconds.Let me know what > improvements people see? > OMIT_GCC=yes do-cm3-std probably is the best test.alarmthreads > platforms (PPC_LINUX), no change (still rebuilding actually). That's great. I'll let you know this evening how it works for me. > NT386GNU still seems just as slow. IIRC, process creation (fork) was always really slow in Cygwin. You cannot expect to be better than the underlying platform :-/ > At some point I will try batching up the cm3cg and/or as calls. > Maybe via a wrapper on Windows only that then just makes n Win32 > CreateProcess calls instead of n Cygwin vforks. > It might be nice to have Quake callouts for before_first_compile, > after_last_compile, before_first_assemble, after_last_assemble, > though this brings up that there should perhaps be > begin_package/end_package, for cm3 to become a multi-package > builder..and then, really, multi-threaded, so there'd have to be > maybe extra state variables passed around, maybe. (and then Cygwin's > waitpid not being threadsafe breaks this...) What we really should do to speed things up on modern multi-core processors is to implement parallel compilation (both front-end and back-end) of sources. This should be possible now that we have native thread support in M3. It will probably need some design changes though; I haven't looked into it, though I often thought this was a missing feature. Olaf > (For prototyping, before_first compile is implied, > after_last_compile/assemble is implied by make_lib/skip_lib/link, so > any queuing up could be flushed at that point. Goal here being not > to reduce process creates, but cygwin processes created from cygwin > processes. oh, and I just realized, cm3cg should probably mark all > data as "no copy" when targeting Cygwin. That might help a bunch.) > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Feb 28 15:09:14 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 09:09:14 -0500 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> Message-ID: <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> No, please don't do that!!!! I hate it when I get a huge file of diffs. The comment should be descriptive enough to let me know if I care about the diffs or not. As an emacs user it is trivial for me to browse diffs there if I *really* care. But e-mail is the *wrong* place for diffs!! On Feb 28, 2008, at 4:25 AM, Jay wrote: > Is it easy enough for the commit mails to contain links to view all > of the diffs described? > That's be super duper nice. > I find browsing the cvsweb very inefficient. > > - Jay > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: FW: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:59:47 +0000 > > truncated again! and possibly misformated.. > > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the privacy/size/same- > across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command line > option. I will always turn it on. :) > > - Jay > > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines or > does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number > yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 28 15:12:21 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 09:12:21 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: I'm not sure what you mean here... Please explain further... On Feb 28, 2008, at 8:03 AM, Jay wrote: > Done. > On birch, > time sh -c "./do-pkg.sh realclean libm3 && ./do-pkg.sh buildship > libm3" > > seems go from about 35 seconds to about 15 seconds. > Let me know what improvements people see? > OMIT_GCC=yes do-cm3-std probably is the best test. > alarmthreads platforms (PPC_LINUX), no change (still rebuilding > actually). > > NT386GNU still seems just as slow. > At some point I will try batching up the cm3cg and/or as calls. > Maybe via a wrapper on Windows only that then just makes n Win32 > CreateProcess calls instead of n Cygwin vforks. > It might be nice to have Quake callouts for before_first_compile, > after_last_compile, before_first_assemble, after_last_assemble, > though this brings up that there should perhaps be begin_package/ > end_package, for cm3 to become a multi-package builder..and then, > really, multi-threaded, so there'd have to be maybe extra state > variables passed around, maybe. (and then Cygwin's waitpid not being > threadsafe breaks this...) > > (For prototyping, before_first compile is implied, > after_last_compile/assemble is implied by make_lib/skip_lib/link, so > any queuing up could be flushed at that point. Goal here being not > to reduce process creates, but cygwin processes created from cygwin > processes. oh, and I just realized, cm3cg should probably mark all > data as "no copy" when targeting Cygwin. That might help a bunch.) > > - Jay > > > > > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] nt386gnu threads? > > Date: Tue, 29 Jan 2008 08:08:38 -0500 > > To: mika at async.caltech.edu > > > > Indeed. We definitely need to fix this... > > > > > > On Jan 29, 2008, at 5:45 AM, Mika Nystrom wrote: > > > > > Jay writes: > > > .. > > >> It is painfully noticable how much more slowly NT386GNU m3cc > > >> builds than NT= > > >> 386MINGNU m3cc, presumably due to the underlying slower bash/sed/ > > >> make etc. > > > .. > > > > > > are you sure it's not the Thread.Sleep(0.1d0) in Process.Wait? > > > > > > Mika > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Feb 28 19:22:50 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 19:22:50 +0100 Subject: [M3devel] multiple pkg roots? Message-ID: <1204222970.13580.62.camel@hias.m3w.org> Is it possible to ship to more than one location, and/or have system find package imported in list of locations, instead from one location? dd -- Dragi?a Duri? From jayk123 at hotmail.com Thu Feb 28 19:47:45 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 18:47:45 +0000 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> References: <20080228082322.3662910D46B6@birch.elegosoft.com> <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> Message-ID: Links, not diffs. - Jay CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] put full paths to source files in debug infoDate: Thu, 28 Feb 2008 09:09:14 -0500 No, please don't do that!!!! I hate it when I get a huge file of diffs. The comment should be descriptive enough to let me know if I care about the diffs or not. As an emacs user it is trivial for me to browse diffs there if I *really* care. But e-mail is the *wrong* place for diffs!! On Feb 28, 2008, at 4:25 AM, Jay wrote: Is it easy enough for the commit mails to contain links to view all of the diffs described?That's be super duper nice.I find browsing the cvsweb very inefficient. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:59:47 +0000truncated again! and possibly misformated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:44:11 +0000pps: "webinfo" (Reactor?) and assertion failures are affected by this also, but not fully. Before you would have gotten: ****** runtime error:*** <*ASSERT*> failed.*** file "WaitProcessCygwin.m3", line 16*** but now you get: ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16***I'd say the realpath call (or whatever the portable Modula-3 library call is) should be moved up to m3front to address these, and the parse.c change undone. As well, I believe resolving symlinks is happening too but that wasn't the point, so something instead of realpath might be preferable. Like, just see if the string starts ".\" or "..\", it will almost always start "..\", and if so, prepend current working directory and then workout the dots. It may also be reasonable to provide paths to the compiler to remove from the starts of paths, which would likely address the symlink issue, since they are more likely to be nearer the start of the path than the middle or end. As well as partly the privacy/size/same-across-machines issues. In any case, I think this easy small change is already very useful progress. Or does everyone else just fill up .gdbinit with dir commands? It seems to me that it shouldn't even that difficult, even if it isn't very difficult. Agreed? - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: Thu, 28 Feb 2008 08:31:32 +0000ps: does anyone care that binaries built from different cvs checkouts, but otherwise identical source, will no longer match, unless perhaps they are "stripped"? If so, or if any of the other issues bug people, or any other problem is brought up or discovered, this can be made a command line option. I will always turn it on. :) - Jay > Date: Thu, 28 Feb 2008 09:23:22 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/28 09:23:22> > Modified files:> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > Scanner.m3 > > Log message:> put full paths to source files in debug info> > This has the minor downsides of:> 1) grows the debug info (it is already huge; who is counting?)> 2) reveals file system layout in debug info (privacy?)> 3) does it inhibit debugging files from other people's machines or does gdb dir still work?> > but definitely makes for a more pleasant debugging experience when> debugging stuff you have built yourself.> > The linear searching to see if a name has been allocated a number yet> will obviously slow way down due to a large increase in common prefixes,> but that should be a hash table anyway. Linear search is lame.> (or a trie, but working from the ends of the strings, minus the last one or few> characters, due to common prefixes as well as common suffixes)> > Note that both m3front and m3cc changes are needed as m3front has paths> relative to the current working directory or such.> > For most packages, you can get by without the m3front change and just prepend> "../src/" to the path in m3cc, but that doesn't work for hierarchical packages> such as libm3 and m3core which I am debugging. Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 28 19:49:25 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 28 Feb 2008 18:49:25 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Message-ID: > You cannot expect to be better than the underlying platform :-/ Cygwin is much slower than the underying platform I believe.. - Jay [snip] _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Feb 28 20:05:34 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 13:05:34 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] Message-ID: <47C705FE.7090005@wichita.edu> I don't understand what the need for these paths is. In every complete program, all the interfaces and all the modules must have unique simple names, otherwise code could not refer to them. With the filename matchup rules, this should make all the simple file names unique too. So any debug commands should never need a path. And using simple names avoids the problems of moving compiled code. Is it more output from the debugger you want? If so, this could no doubt be done by the debugger itself with the debug info as it was. It already contained one copy of the full path to the source file in each object file, though I don't know of a place the debugger uses this now. Yes, I know the filename/modulename rules don't actually apply for modules, but not following them is a bad practice. I've been around that block many times with Ada, and believe me, it's a nightmare. Furthermore, then you wouldn't be able to name things in the debugger as ModuleName.VarOrProcInModule, This construct does not exist in code but is very useful in debugging, especially when InterfaceName/ModuleName is not one-to-one, e.g. when a module exports >1 interface, etc. Jay wrote: > truncated again! and possibly misformated.. > > > > > ------------------------------------------------------------------------ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the > privacy/size/same-across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > ------------------------------------------------------------------------ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command > line option. I will always turn it on. :) > > - Jay > > ------------------------------------------------------------------------ > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines > or does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your Hotmail?-get > your "fix". Check it out. -- ------------------------------------------------------------- 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 dragisha at m3w.org Thu Feb 28 20:13:21 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 20:13:21 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? Message-ID: <1204226001.13580.64.camel@hias.m3w.org> I am probably missing it, and few of my last runs had some problems... So - what is current state of m3gdb on LINUXLIBC6? Working? Under fixing? TIA, dd -- Dragi?a Duri? From hosking at cs.purdue.edu Thu Feb 28 20:13:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 14:13:48 -0500 Subject: [M3devel] put full paths to source files in debug info In-Reply-To: References: <20080228082322.3662910D46B6@birch.elegosoft.com> <1249DB85-554D-4E97-8C61-65D621379B13@cs.purdue.edu> Message-ID: <4CD621A0-B1CA-4B2B-8C79-5B7CFD577186@cs.purdue.edu> Sorry, read your message too quickly. Yes, links might be nice.... :-) On Feb 28, 2008, at 1:47 PM, Jay wrote: > Links, not diffs. > > - Jay > > > > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] put full paths to source files in debug info > Date: Thu, 28 Feb 2008 09:09:14 -0500 > > No, please don't do that!!!! I hate it when I get a huge file of > diffs. The comment should be descriptive enough to let me know if I > care about the diffs or not. As an emacs user it is trivial for me > to browse diffs there if I *really* care. But e-mail is the *wrong* > place for diffs!! > > On Feb 28, 2008, at 4:25 AM, Jay wrote: > > Is it easy enough for the commit mails to contain links to view all > of the diffs described? > That's be super duper nice. > I find browsing the cvsweb very inefficient. > > - Jay > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: FW: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:59:47 +0000 > > truncated again! and possibly misformated.. > > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:44:11 +0000 > > pps: "webinfo" (Reactor?) and assertion failures are affected by > this also, but not fully. > > Before you would have gotten: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "WaitProcessCygwin.m3", line 16 > *** > > but now you get: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > *** > > I'd say the realpath call (or whatever the portable Modula-3 library > call is) should be moved up to m3front to address these, and the > parse.c change undone. > > As well, I believe resolving symlinks is happening too but that > wasn't the point, so something instead of realpath might be > preferable. Like, just see if the string starts ".\" or "..\", it > will almost always start "..\", and if so, prepend current working > directory and then workout the dots. > > It may also be reasonable to provide paths to the compiler to remove > from the starts of paths, which would likely address the symlink > issue, since they are more likely to be nearer the start of the path > than the middle or end. As well as partly the privacy/size/same- > across-machines issues. > > In any case, I think this easy small change is already very useful > progress. Or does everyone else just fill up .gdbinit with dir > commands? It seems to me that it shouldn't even that difficult, even > if it isn't very difficult. > > Agreed? > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: re: put full paths to source files in debug info > Date: Thu, 28 Feb 2008 08:31:32 +0000 > > ps: does anyone care that binaries built from different cvs > checkouts, but otherwise identical source, will no longer match, > unless perhaps they are "stripped"? > > If so, or if any of the other issues bug people, or any other > problem is brought up or discovered, this can be made a command line > option. I will always turn it on. :) > > - Jay > > > > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/28 09:23:22 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > Scanner.m3 > > > > Log message: > > put full paths to source files in debug info > > > > This has the minor downsides of: > > 1) grows the debug info (it is already huge; who is counting?) > > 2) reveals file system layout in debug info (privacy?) > > 3) does it inhibit debugging files from other people's machines or > does gdb dir still work? > > > > but definitely makes for a more pleasant debugging experience when > > debugging stuff you have built yourself. > > > > The linear searching to see if a name has been allocated a number > yet > > will obviously slow way down due to a large increase in common > prefixes, > > but that should be a hash table anyway. Linear search is lame. > > (or a trie, but working from the ends of the strings, minus the > last one or few > > characters, due to common prefixes as well as common suffixes) > > > > Note that both m3front and m3cc changes are needed as m3front has > paths > > relative to the current working directory or such. > > > > For most packages, you can get by without the m3front change and > just prepend > > "../src/" to the path in m3cc, but that doesn't work for > hierarchical packages > > such as libm3 and m3core which I am debugging. > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 28 20:12:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 14:12:33 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <47C705FE.7090005@wichita.edu> References: <47C705FE.7090005@wichita.edu> Message-ID: <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> I concur with Rodney on this. There are deeper issues here than simply avoiding the need to use dir in gdb. On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > I don't understand what the need for these paths is. In every > complete > program, all the interfaces and all the modules must have unique > simple > names, otherwise code could not refer to them. With the filename > matchup > rules, this should make all the simple file names unique too. So any > debug commands should never need a path. And using simple names > avoids > the problems of moving compiled code. > > Is it more output from the debugger you want? If so, this could no > doubt > be done by the debugger itself with the debug info as it was. It > already > contained one copy of the full path to the source file in each > object file, > though I don't know of a place the debugger uses this now. > > Yes, I know the filename/modulename rules don't actually apply for > modules, > but not following them is a bad practice. I've been around that > block many > times with Ada, and believe me, it's a nightmare. Furthermore, then > you > wouldn't be able to name things in the debugger as > ModuleName.VarOrProcInModule, > This construct does not exist in code but is very useful in > debugging, especially > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > exports >1 > interface, etc. > > Jay wrote: >> truncated again! and possibly misformated.. >> >> ------------------------------------------------------------------------ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: RE: put full paths to source files in debug info >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> pps: "webinfo" (Reactor?) and assertion failures are affected by >> this also, but not fully. >> Before you would have gotten: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "WaitProcessCygwin.m3", line 16 >> *** >> but now you get: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> *** >> I'd say the realpath call (or whatever the portable Modula-3 >> library >> call is) should be moved up to m3front to address these, and the >> parse.c change undone. >> As well, I believe resolving symlinks is happening too but >> that >> wasn't the point, so something instead of realpath might be >> preferable. Like, just see if the string starts ".\" or "..\", it >> will almost always start "..\", and if so, prepend current working >> directory and then workout the dots. >> It may also be reasonable to provide paths to the compiler >> to remove >> from the starts of paths, which would likely address the symlink >> issue, since they are more likely to be nearer the start of the >> path >> than the middle or end. As well as partly the >> privacy/size/same-across-machines issues. >> In any case, I think this easy small change is already very >> useful >> progress. Or does everyone else just fill up .gdbinit with dir >> commands? It seems to me that it shouldn't even that difficult, >> even >> if it isn't very difficult. >> Agreed? >> - Jay >> >> ------------------------------------------------------------------------ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: re: put full paths to source files in debug info >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> ps: does anyone care that binaries built from different cvs >> checkouts, but otherwise identical source, will no longer match, >> unless perhaps they are "stripped"? >> If so, or if any of the other issues bug people, or any other >> problem is brought up or discovered, this can be made a command >> line option. I will always turn it on. :) >> - Jay >> >> ------------------------------------------------------------------------ >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> > To: m3commit at elegosoft.com >> > From: jkrell at elego.de >> > Subject: [M3commit] CVS Update: cm3 >> > >> > CVSROOT: /usr/cvs >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> > >> > Modified files: >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> > Scanner.m3 >> > >> > Log message: >> > put full paths to source files in debug info >> > >> > This has the minor downsides of: >> > 1) grows the debug info (it is already huge; who is counting?) >> > 2) reveals file system layout in debug info (privacy?) >> > 3) does it inhibit debugging files from other people's machines >> or does gdb dir still work? >> > >> > but definitely makes for a more pleasant debugging experience >> when >> > debugging stuff you have built yourself. >> > >> > The linear searching to see if a name has been allocated a >> number yet >> > will obviously slow way down due to a large increase in common >> prefixes, >> > but that should be a hash table anyway. Linear search is lame. >> > (or a trie, but working from the ends of the strings, minus the >> last one or few >> > characters, due to common prefixes as well as common suffixes) >> > >> > Note that both m3front and m3cc changes are needed as m3front >> has >> paths >> > relative to the current working directory or such. >> > >> > For most packages, you can get by without the m3front change >> and >> just prepend >> > "../src/" to the path in m3cc, but that doesn't work for >> hierarchical packages >> > such as libm3 and m3core which I am debugging. >> ------------------------------------------------------------------------ >> Need to know the score, the latest news, or you need your Hotmail?- >> get your "fix". Check it out. > > > > -- > ------------------------------------------------------------- > 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 Feb 28 21:11:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 21:11:07 +0100 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> <20080228142855.mc0brmis6ck8sck0@mail.elegosoft.com> Message-ID: <20080228211107.vkj5tlcs08c4csss@mail.elegosoft.com> Quoting Jay : >> You cannot expect to be better than the underlying platform :-/ > Cygwin is much slower than the underying platform I believe.. Thast's what I meant. You (CM3) cannot be better than Cygwin on NT386GNU. It's a problem of the Cygwin platform (not of CM3 and not of 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 wagner at elegosoft.com Thu Feb 28 21:18:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Feb 2008 21:18:36 +0100 Subject: [M3devel] multiple pkg roots? In-Reply-To: <1204222970.13580.62.camel@hias.m3w.org> References: <1204222970.13580.62.camel@hias.m3w.org> Message-ID: <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> Quoting Dragi?a Duri? : > Is it possible to ship to more than one location, and/or have system > find package imported in list of locations, instead from one location? This is currently only possible with overrides. CM3 does not support multiple package pools, though that would be a nice extension. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu Feb 28 21:42:13 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 28 Feb 2008 21:42:13 +0100 Subject: [M3devel] multiple pkg roots? In-Reply-To: <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> References: <1204222970.13580.62.camel@hias.m3w.org> <20080228211836.3zz7vjxu0wc0w4cw@mail.elegosoft.com> Message-ID: <1204231333.13580.69.camel@hias.m3w.org> And, if overriden, then we cannot ship that package... I am looking at M3Build.m3 now... One of spaghetti pieces of cm3 :) dd On Thu, 2008-02-28 at 21:18 +0100, Olaf Wagner wrote: > Quoting Dragi?a Duri? : > > > Is it possible to ship to more than one location, and/or have system > > find package imported in list of locations, instead from one location? > > This is currently only possible with overrides. CM3 does not support > multiple package pools, though that would be a nice extension. > > Olaf -- Dragi?a Duri? From rodney.bates at wichita.edu Fri Feb 29 00:54:32 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 17:54:32 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204226001.13580.64.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> Message-ID: <47C749B8.1060906@wichita.edu> I have a long list of things to fix/improve in m3gdb, which I periodically work on. But it builds and runs for LINUXLIBC6 and does lots of useful thins. Just minutes ago, I happened to build it on a newly-installed Ubuntu, on LINUXLIBC6 and it is working as expected. For Ubuntu, I had to install package libncurses5-dev (apt-get install libncurses-dev) to get it to build. do-cm3-std.sh did not build it. I will check in my do-cm3-m3gdb.sh, which is a convenient way to build it. There is currently an annoying new bug in displaying subrange values in cm3-compiled code, that often incorrectly thinks the type's range is empty, and then complains the value is out of range. It does give you the numeric value anyway. I have added lots of new stuff to the expression evaluation in the past few years. You can type unmangled, qualified names of variables and procedures, execute procedure and method calls, etc. Much of this is summarized in the various checkin comments, which is, of course, not very handy as a way to read up. It has been on my list to write something up on this. As for other platforms, I don't have any around, and I'm not aware of anybody trying it. Dragi?a Duri? wrote: > I am probably missing it, and few of my last runs had some problems... > So - what is current state of m3gdb on LINUXLIBC6? Working? Under > fixing? > > TIA, > dd -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 01:25:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 28 Feb 2008 18:25:36 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204226001.13580.64.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> Message-ID: <47C75100.9040004@wichita.edu> P.S. m3gdb dynamically detects and adapts to cm3 or pm3- compiled code (or src or ezm3). Also the integrated back end or the gcc-derived back ends. In cm3, code needs to be compiled with -gstabs+. Dragi?a Duri? wrote: > I am probably missing it, and few of my last runs had some problems... > So - what is current state of m3gdb on LINUXLIBC6? Working? Under > fixing? > > TIA, > dd -- ------------------------------------------------------------- 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 Fri Feb 29 01:19:36 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 Feb 2008 01:19:36 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C749B8.1060906@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> Message-ID: <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> Quoting "Rodney M. Bates" : > As for other platforms, I don't have any around, and I'm not aware of anybody > trying it. It compiles without problems on FreeBSD 6.3 and works as long as programs are linked with libthr.so (not with libpthread.so). I haven't used it much yet, and some things seemed to be strange; thread stack switching or viewing didn't work at all. If you want to try anything on FreeBSD, let me know, I can provide a remote login. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Feb 29 02:01:02 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:01:02 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad? What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume. As is setting them by full name PosixProcess__WaitProcess. That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number. Do people do that? I guess the gui wrappers do, but I assume that'd still work. ? Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching? Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience. Gdb automatically shows me the source as I step, instead of just file name and line number. cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom: void assert_failed(const char* condition, const char* file, unsigned line); #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also: printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths. I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:36:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:36:08 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:35:25 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:35:25 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 04:01:42 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 22:01:42 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> On Feb 28, 2008, at 8:01 PM, Jay wrote: > Are you all serious? Telling the debugger the full path to source > files via the debuginfo is bad? > What are the issues? I want to know so that when I use the switch I > know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb > a few weeks ago). > > What I could imagine is affected is setting them by file and line > number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a > full path? Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not. > Gdb doesn't have any fuzzy matching? Not sure. > Maybe in gcc I can give multiple file names? Again, not sure. > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so > by default gdb was showing hardly anything at all, quite poor. I > admit, I'm at the start of the learning curve on gdb. I had to look > to find the dir command. I had to look to find display/x $pc. To use > the dir command, I have to constantly switch my slashes, since I get > the paths from dir /s/b. I use gdb under emacs... if the emacs bindings continue to work then OK, but if not then problems. > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned > line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. I look forward to Rodney's input since he has most experience with m3gdb and its expectations, and moreover with the current behavior of gdb for other languages. > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So > any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, > then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current > working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your > Hotmail?- > > >> get your "fix". Check it out. > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 04:02:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 28 Feb 2008 22:02:23 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <4A155BD0-9DBF-4F25-96D5-C4AE16F61F62@cs.purdue.edu> Before we decide a switch is needed, can anyone tell me what gcc does by default for C? Does gcc have a switch already? On Feb 28, 2008, at 8:36 PM, Jay wrote: > If this must be a switch, what should the default be? > I suspect the default should be full paths. > > And then, should there be switches for each of: > debuginfo > assertions > webinfo > > "assertions" actually use the Modula-3 equivalent of __FILE__. > And so, what this should perhaps looks like is, using bogus Cish > names, > __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/ > unix/usomething.m3) > __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix > \fooposix.m3) > __LEAF_FILE__ (e.g. fooposix.m3) > > or maybe just the first two, and maybe the one that exists today > retains its meaning and a new "full file" is introduced. And then > folks can use it if they wish, and assertion maybe honors a switch. > > I hate to make everything TOO flexible and configurable though. It > can get confusing, and the underutilized options may get undertested > (but better now with increasing automated testing). > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; rodney.bates at wichita.edu > Date: Fri, 29 Feb 2008 01:01:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > Are you all serious? Telling the debugger the full path to source > files via the debuginfo is bad? > What are the issues? I want to know so that when I use the switch I > know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb > a few weeks ago). > > What I could imagine is affected is setting them by file and line > number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a > full path? > Gdb doesn't have any fuzzy matching? > Maybe in gcc I can give multiple file names? > > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so > by default gdb was showing hardly anything at all, quite poor. I > admit, I'm at the start of the learning curve on gdb. I had to look > to find the dir command. I had to look to find display/x $pc. To use > the dir command, I have to constantly switch my slashes, since I get > the paths from dir /s/b. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned > line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug > info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So > any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, > then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current > working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your > Hotmail?- > > >> get your "fix". Check it out. > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 04:52:50 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 03:52:50 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> Message-ID: > ...debugger itself with the debug info as it was. It already> > contained one copy of the full path to the source file in each > > object file, though I don't know of a place the debugger uses this now.btw, I don't think this part is true. I don't believe the object files contain full source paths anywhere. But oops, I admit I didn't open the .ms or .mo files and double check that. However, "the way it works", where "it" is the little bit of code I looked at, is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that path was passed in to gcc. My experience with gdb strongly suggests that this sort of path is the only one in the debug info. I will check more stuff tonight, the behavior of __FILE__, the behavior of gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the behavior of emacs+gdb (yet another learning curve..man, being low in the callstack requires familiarity with everyone's workflow above you..) I wonder as well if a list of directories can be put in the debug info. You know, partly as a size optimization, and possibly to address these issues. (of course the size optimization could be independently implemented) When I stepping, I don't really need gdb to show me the full path, that is often but not always noise, I just need it to know the full path so it can show the source. As things were, gdb wouldn't find source without dir commands. Command line debuggers are quite daunting. I don't know if it is worthwhile to strive to reduce the fear and pain they cause, or just suck it all up because you'll hardly make much of a dent anyway. ? - Jay CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to source files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500 On Feb 28, 2008, at 8:01 PM, Jay wrote: Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path? Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not. Gdb doesn't have any fuzzy matching? Not sure. Maybe in gcc I can give multiple file names? Again, not sure. This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I use gdb under emacs... if the emacs bindings continue to work then OK, but if not then problems. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. I look forward to Rodney's input since he has most experience with m3gdb and its expectations, and moreover with the current behavior of gdb for other languages. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Feb 29 10:39:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 29 Feb 2008 01:39:43 -0800 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: Your message of "Fri, 29 Feb 2008 03:52:50 GMT." Message-ID: <200802290939.m1T9dhnk058397@camembert.async.caltech.edu> I'm pretty sure I've seen full paths in ASSERT failures, using, perhaps, ezm3? It didn't cause any gdb problems (I use the old m3gdb a lot). Mika Jay writes: >--_93b0d79c-137f-47e2-9518-78e460fd7ea0_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> ...debugger itself with the debug info as it was. It already> > contained= > one copy of the full path to the source file in each > > object file, thou= >gh I don't know of a place the debugger uses this now.btw, I don't think th= >is part is true. >I don't believe the object files contain full source paths anywhere. >But oops, I admit I didn't open the .ms or .mo files and double check that. >However, "the way it works", where "it" is the little bit of code I looked = >at, >is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that >path was passed in to gcc. >=20 >My experience with gdb strongly suggests that this sort of path is the only >one in the debug info. >=20 >I will check more stuff tonight, the behavior of __FILE__, the behavior of = >gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the = >behavior of emacs+gdb (yet another learning curve..man, being low in the ca= >llstack requires familiarity with everyone's workflow above you..) >=20 >I wonder as well if a list of directories can be put in the debug info. >You know, partly as a size optimization, and possibly to address these issu= >es. > (of course the size optimization could be independently implemented) >When I stepping, I don't really need gdb to show me the full path, that is = >often but not always noise, I just need it to know the full path so it can = >show the source. As things were, gdb wouldn't find source without dir comma= >nds. >=20 >Command line debuggers are quite daunting. >I don't know if it is worthwhile to strive to reduce the fear and pain they= > cause, or just suck it all up because you'll hardly make much of a dent an= >yway. ? >=20 > - Jay > > >CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.= >eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to sour= >ce files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500 > > >On Feb 28, 2008, at 8:01 PM, Jay wrote: > > >Are you all serious? Telling the debugger the full path to source files via= > the debuginfo is bad?What are the issues? I want to know so that when I us= >e the switch I know what trouble I'm bringing myself. Setting breakpoints i= >n "modules", as .dll/.so files, is unaffected I presume.As is setting them = >by full name PosixProcess__WaitProcess.That is what I "always" do ("always"= > as in, I just started using gdb a few weeks ago). What I could imagine is = >affected is setting them by file and line number.Do people do that? I guess= > the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I = >should try out xcode and ddd and such? Do people say like break foo.c:#123?= > And now I've made them use a full path? > >Yes, I do this all the time...via the emacs keybindings -- not sure if full= > paths would break things or not. > >Gdb doesn't have any fuzzy matching? >Not sure. > > >Maybe in gcc I can give multiple file names? > >Again, not sure. > >This really greatly improves the out-of-the-box minimally configured debugg= >ing experience.Gdb automatically shows me the source as I step, instead of = >just file name and line number.cdb/windbg at least show disassembly by defa= >ult, but gdb doesn't, so by default gdb was showing hardly anything at all,= > quite poor. I admit, I'm at the start of the learning curve on gdb. I had = >to look to find the dir command. I had to look to find display/x $pc. To us= >e the dir command, I have to constantly switch my slashes, since I get the = >paths from dir /s/b. > >I use gdb under emacs... if the emacs bindings continue to work then OK, b= >ut if not then problems. > >I will make it a switch in cm3 and cm3cg if it is really a problem. In C it= > is a common idiom:void assert_failed(const char* condition, const char* fi= >le, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FI= >LE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the = >compiler on the command line", or "full path", depending on implementation.= > Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems li= >ke basic correctness to me, to give a debugger full paths.I'm quite surpris= >ed by the pushback. > >I look forward to Rodney's input since he has most experience with m3gdb an= >d its expectations, and moreover with the current behavior of gdb for other= > languages. > >Assertions I think should also be "fixed" further. And I suspect "webinfo" = >but that could wait until Reactor is available.. - Jay > >> From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 = >Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] = >FW: put full paths to source files in debug info]> > I concur with Rodney o= >n this. There are deeper issues here than > simply avoiding the need to use= > dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> >= > I don't understand what the need for these paths is. In every > > complete= >> > program, all the interfaces and all the modules must have unique > > si= >mple> > names, otherwise code could not refer to them. With the filename > = >> matchup> > rules, this should make all the simple file names unique too. = >So any> > debug commands should never need a path. And using simple names >= > > avoids> > the problems of moving compiled code.> >> > Is it more output = >from the debugger you want? If so, this could no > > doubt> > be done by th= >e debugger itself with the debug info as it was. It > > already> > containe= >d one copy of the full path to the source file in each > > object file,> > = >though I don't know of a place the debugger uses this now.> >> > Yes, I kno= >w the filename/modulename rules don't actually apply for > > modules,> > bu= >t not following them is a bad practice. I've been around that > > block man= >y> > times with Ada, and believe me, it's a nightmare. Furthermore, then > = >> you> > wouldn't be able to name things in the debugger as > > ModuleName.= >VarOrProcInModule,> > This construct does not exist in code but is very use= >ful in > > debugging, especially> > when InterfaceName/ModuleName is not on= >e-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wr= >ote:> >> truncated again! and possibly misformated..> >> > >> -------------= >-----------------------------------------------------------> >> From: jayk1= >23 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full path= >s to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> = >>> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> thi= >s also, but not fully.> >> Before you would have gotten:> >> ***> >> *** ru= >ntime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3"= >, line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *= >** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m= >3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable= > Modula-3 > >> library> >> call is) should be moved up to m3front to addres= >s these, and the> >> parse.c change undone.> >> As well, I believe resolvin= >g symlinks is happening too but > >> that> >> wasn't the point, so somethin= >g instead of realpath might be> >> preferable. Like, just see if the string= > starts ".\" or "..\", it> >> will almost always start "..\", and if so, pr= .. From rodney.bates at wichita.edu Fri Feb 29 17:43:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 10:43:35 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> Message-ID: <47C83637.6010602@wichita.edu> Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> As for other platforms, I don't have any around, and I'm not aware of >> anybody >> trying it. > > > It compiles without problems on FreeBSD 6.3 and works as long as > programs are linked with libthr.so (not with libpthread.so). Any more information on what the difference in these libraries is? > I haven't used it much yet, and some things seemed to be strange; > thread stack switching or viewing didn't work at all. m3gdb needs work on threads. I have never done anything on it. Unless Tony did some when he was working on it several years ago, I think it is pretty much as it came from SRC, and that was fairly primitive. Plus, the new pthreads implementation is not supported. Once I glanced at the code and it looked immediately like what was there would not work at all. This has been on my list a while. > > If you want to try anything on FreeBSD, let me know, I can provide > a remote login. Yes, that would be helpful. > > Olaf -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:11:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:11:35 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: <47C83CC7.9060905@wichita.edu> Jay wrote: > Are you all serious? Telling the debugger the full path to source files > via the debuginfo is bad? Below. > What are the issues? I want to know so that when I use the switch I know > what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is unaffected I > presume. > As is setting them by full name PosixProcess__WaitProcess. In m3gdb, you can also say PosixProcess.WaitProcess. > That is what I "always" do ("always" as in, I just started using gdb a > few weeks ago). > > What I could imagine is affected is setting them by file and line number. > Do people do that? I guess the gui wrappers do, but I assume that'd > still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use a full path? Yes. PosixProcess.m3:123 is the normal way. Since source file simple names are unique, this is enough in Modula-3. I suppose in C, if somebody actually had >1 source file with the same simple name, something messier would be needed, but normally, break Foo.c:123 is the way to do it. Likewise, before your change to debug info, output from (m3)gdb showing where something is stopped uses source file simple names and line numbers too. > Gdb doesn't have any fuzzy matching? > Maybe in gcc I can give multiple file names? > > This really greatly improves the out-of-the-box minimally configured > debugging experience. > Gdb automatically shows me the source as I step, instead of just file > name and line number. > cdb/windbg at least show disassembly by default, but gdb doesn't, so by > default gdb was showing hardly anything at all, quite poor. I admit, I'm > at the start of the learning curve on gdb. I had to look to find the dir > command. I had to look to find display/x $pc. To use the dir command, I > have to constantly switch my slashes, since I get the paths from dir /s/b. The paths to source are used in (m3)gdb only to display a portion of actual source code, not to identify file/line# places. For the former function only, (m3)gdb has to have full paths, and they must be as they may have changed since things were compiled/linked. I put -d command line options for all my source file paths (which do the same thing as dir gdb commands) in a startup file for any project that gets significant work. I do agree, it would be nice for a quick jump into a debugger, not to have to do this. It could only work, of course, if the source files are where they were at the time of compilation. The way to do this is for gdb to try the path from the object module, after normal use of dir/-d paths have failed. Since we can't change gdb, this would only be in m3gdb. On big advantage of this would be that it would work when one needs to debug right into the runtime system, as I do somewhat regularly. That requires several additional paths that one would not ordinarily have specified. The way we are installing Modula-3 now, it is a pretty safe bet that, if the source exists at all, then it where it was when the runtime system was compiled. (Well, copies of the interfaces do get placed in the install directory, but I'm not sure m3gdb ever displays non-executable code, which is all that interfaces have.) You have convinced me to add this to my list. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, unsigned line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) > : (void)0) > We don't have anything like __FILE__ and __LINE__ in Modula-3. I have a largish program full of assertions with it's own coded assertion handling, including recoverable (in a sense, roll back to a consistent state) assertion failures. It could use something like this. But it also seems pretty hackish to me too. > __FILE__ can vary between "the parameter to the compiler on the command > line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a debugger > full paths. People can and often do move executables to different machines and also sometimes move source trees around on the original machine. Using simple file names within an executable (of which there is always exactly one) is invariant to all this, and a lot shorter to type/read. > I'm quite surprised by the pushback. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > To: rodney.bates at wichita.edu > > Date: Thu, 28 Feb 2008 14:12:33 -0500 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] FW: put full paths to source files in debug info] > > > > I concur with Rodney on this. There are deeper issues here than > > simply avoiding the need to use dir in gdb. > > > > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: > > > > > > > > I don't understand what the need for these paths is. In every > > > complete > > > program, all the interfaces and all the modules must have unique > > > simple > > > names, otherwise code could not refer to them. With the filename > > > matchup > > > rules, this should make all the simple file names unique too. So any > > > debug commands should never need a path. And using simple names > > > avoids > > > the problems of moving compiled code. > > > > > > Is it more output from the debugger you want? If so, this could no > > > doubt > > > be done by the debugger itself with the debug info as it was. It > > > already > > > contained one copy of the full path to the source file in each > > > object file, > > > though I don't know of a place the debugger uses this now. > > > > > > Yes, I know the filename/modulename rules don't actually apply for > > > modules, > > > but not following them is a bad practice. I've been around that > > > block many > > > times with Ada, and believe me, it's a nightmare. Furthermore, then > > > you > > > wouldn't be able to name things in the debugger as > > > ModuleName.VarOrProcInModule, > > > This construct does not exist in code but is very useful in > > > debugging, especially > > > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > > exports >1 > > > interface, etc. > > > > > > Jay wrote: > > >> truncated again! and possibly misformated.. > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: RE: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 > > >> pps: "webinfo" (Reactor?) and assertion failures are affected by > > >> this also, but not fully. > > >> Before you would have gotten: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "WaitProcessCygwin.m3", line 16 > > >> *** > > >> but now you get: > > >> *** > > >> *** runtime error: > > >> *** <*ASSERT*> failed. > > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 > > >> *** > > >> I'd say the realpath call (or whatever the portable Modula-3 > > >> library > > >> call is) should be moved up to m3front to address these, and the > > >> parse.c change undone. > > >> As well, I believe resolving symlinks is happening too but > > >> that > > >> wasn't the point, so something instead of realpath might be > > >> preferable. Like, just see if the string starts ".\" or "..\", it > > >> will almost always start "..\", and if so, prepend current working > > >> directory and then workout the dots. > > >> It may also be reasonable to provide paths to the compiler > > >> to remove > > >> from the starts of paths, which would likely address the symlink > > >> issue, since they are more likely to be nearer the start of the > > >> path > > >> than the middle or end. As well as partly the > > >> privacy/size/same-across-machines issues. > > >> In any case, I think this easy small change is already very > > >> useful > > >> progress. Or does everyone else just fill up .gdbinit with dir > > >> commands? It seems to me that it shouldn't even that difficult, > > >> even > > >> if it isn't very difficult. > > >> Agreed? > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> From: jayk123 at hotmail.com > > >> To: m3devel at elegosoft.com > > >> Subject: re: put full paths to source files in debug info > > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 > > >> ps: does anyone care that binaries built from different cvs > > >> checkouts, but otherwise identical source, will no longer match, > > >> unless perhaps they are "stripped"? > > >> If so, or if any of the other issues bug people, or any other > > >> problem is brought up or discovered, this can be made a command > > >> line option. I will always turn it on. :) > > >> - Jay > > >> > > >> > ------------------------------------------------------------------------ > > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 > > >> > To: m3commit at elegosoft.com > > >> > From: jkrell at elego.de > > >> > Subject: [M3commit] CVS Update: cm3 > > >> > > > >> > CVSROOT: /usr/cvs > > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 > > >> > > > >> > Modified files: > > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 > > >> > Scanner.m3 > > >> > > > >> > Log message: > > >> > put full paths to source files in debug info > > >> > > > >> > This has the minor downsides of: > > >> > 1) grows the debug info (it is already huge; who is counting?) > > >> > 2) reveals file system layout in debug info (privacy?) > > >> > 3) does it inhibit debugging files from other people's machines > > >> or does gdb dir still work? > > >> > > > >> > but definitely makes for a more pleasant debugging experience > > >> when > > >> > debugging stuff you have built yourself. > > >> > > > >> > The linear searching to see if a name has been allocated a > > >> number yet > > >> > will obviously slow way down due to a large increase in common > > >> prefixes, > > >> > but that should be a hash table anyway. Linear search is lame. > > >> > (or a trie, but working from the ends of the strings, minus the > > >> last one or few > > >> > characters, due to common prefixes as well as common suffixes) > > >> > > > >> > Note that both m3front and m3cc changes are needed as m3front > > >> has > > >> paths > > >> > relative to the current working directory or such. > > >> > > > >> > For most packages, you can get by without the m3front change > > >> and > > >> just prepend > > >> > "../src/" to the path in m3cc, but that doesn't work for > > >> hierarchical packages > > >> > such as libm3 and m3core which I am debugging. > > >> > ------------------------------------------------------------------------ > > >> Need to know the score, the latest news, or you need your Hotmail?- > > >> get your "fix". Check it out. > > >> > > > > > > > -- > > > ------------------------------------------------------------- > > > 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 > > > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your Hotmail?-get > your "fix". Check it out. -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:18:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:18:15 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204267238.13580.75.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <1204267238.13580.75.camel@hias.m3w.org> Message-ID: <47C83E57.4060202@wichita.edu> Hmm. I'm not sure what happens here. It will be the same as the stock gdb (6.4) from which m3gdb is derived. I think it has a way of getting debug info from separate files, but I have never used this. The m3gdb changes to gdb don't do anything about this. I have, a few times, at intervals of two or three years, forward ported (back ported? what does one call this?) the Modula-3 changes into newer gdb releases. If there is something in the newest gdb that is really needed, I can do that again, although when I last thought about it (6.7), there was some target gdb had dropped that we still have in cm3. Dragi?a Duri? wrote: > During RPM building process, rpmbuild strips debug info and packs it > separatelly. Is m3gbd recognizing this situation and using debug info > in, for example: > > /usr/lib/debug/usr/local/cm3/bin/m3gdb.debug > /usr/lib/debug/usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/parseparams/LINUXLIBC6/libm3parseparams.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/set/LINUXLIBC6/libset.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/tcp/LINUXLIBC6/libm3tcp.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/tempfiles/LINUXLIBC6/libTempFiles.so.5.debug > /usr/lib/debug/usr/local/cm3/pkg/udp/LINUXLIBC6/libUDP.so.5.debug > > TIA, > dd > > On Thu, 2008-02-28 at 17:54 -0600, Rodney M. Bates wrote: > >>I have a long list of things to fix/improve in m3gdb, which I periodically >>work on. But it builds and runs for LINUXLIBC6 and does lots of useful thins. >> >>Just minutes ago, I happened to build it on a newly-installed Ubuntu, on >>LINUXLIBC6 and it is working as expected. For Ubuntu, I had to install >>package libncurses5-dev (apt-get install libncurses-dev) to get it to >>build. do-cm3-std.sh did not build it. I will check in my do-cm3-m3gdb.sh, >>which is a convenient way to build it. >> >>There is currently an annoying new bug in displaying subrange values in >>cm3-compiled code, that often incorrectly thinks the type's range is empty, >>and then complains the value is out of range. It does give you the numeric >>value anyway. >> >>I have added lots of new stuff to the expression evaluation in the past few >>years. You can type unmangled, qualified names of variables and procedures, >>execute procedure and method calls, etc. Much of this is summarized in the >>various checkin comments, which is, of course, not very handy as a way to >>read up. It has been on my list to write something up on this. >> >>As for other platforms, I don't have any around, and I'm not aware of anybody >>trying it. >> >>Dragi?a Duri? wrote: >> >>>I am probably missing it, and few of my last runs had some problems... >>>So - what is current state of m3gdb on LINUXLIBC6? Working? Under >>>fixing? >>> >>>TIA, >>>dd >> -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 18:32:49 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 11:32:49 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <66FA5D65-9BB0-4C2D-B09D-DBD74BA06389@cs.purdue.edu> Message-ID: <47C841C1.3090202@wichita.edu> Jay wrote: > > ...debugger itself with the debug info as it was. It already > > > contained one copy of the full path to the source file in each > > > object file, though I don't know of a place the debugger uses this now. > > btw, I don't think this part is true. > I don't believe the object files contain full source paths anywhere. > But oops, I admit I didn't open the .ms or .mo files and double check that. > However, "the way it works", where "it" is the little bit of code I > looked at, > is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that > path was passed in to gcc. > > My experience with gdb strongly suggests that this sort of path is the only > one in the debug info. Evidence: ----------------------------------------------------------------------------------------------- [rodney at selkirk LINUXLIBC6]$ objdump -G Sets.mo | more Sets.mo: file format elf32-i386 Contents of .stab section: Symnum n_type n_othr n_desc n_value n_strx String -1 HdrSym 0 839 00001db3 1 0 SO 0 0 00000000 9 /home/rodney/proj/util/m3/ordsets/LINUXLIBC6/ 1 SO 0 0 00000000 55 Sets.mc 2 OPT 0 0 00000000 63 gcc2_compiled. ... A bunch of irrelevant type definitions deleted ......... 3 LSYM 0 0 00000000 78 26 SOL 0 0 00000000 1353 Sets.m3 ----------------------------------------------------------------------------------------------- This is from an earlier compiler, before your change. Your change shows up in the last line, in front of Sets.m3. The path in the separate SO line is to the compiled object file, not the source. For Modula-3, getting the source file is usually trivial, although not always, especially the RTS. When changing m3gdb to use this after normal dir/-d paths have failed, I would consider changing cm3 to emit a 3rd SO line with the source path, *IF* this didn't choke stock gdb, which I doubt it would. However m3gdb works on code compiled by all the compilers, including older versions of cm3, so perhaps searching below ../src would be needed anyway. > > I will check more stuff tonight, the behavior of __FILE__, the behavior > of gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and > MAYBE the behavior of emacs+gdb (yet another learning curve..man, being > low in the callstack requires familiarity with everyone's workflow above > you..) > > I wonder as well if a list of directories can be put in the debug info. > You know, partly as a size optimization, and possibly to address these > issues. > (of course the size optimization could be independently implemented) > When I stepping, I don't really need gdb to show me the full path, that > is often but not always noise, I just need it to know the full path so > it can show the source. As things were, gdb wouldn't find source without > dir commands. > > Command line debuggers are quite daunting. > I don't know if it is worthwhile to strive to reduce the fear and pain > they cause, or just suck it all up because you'll hardly make much of a > dent anyway. ? > > - Jay > > ------------------------------------------------------------------------ > CC: rodney.bates at wichita.edu; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > To: jayk123 at hotmail.com > Subject: Re: [M3devel] FW: put full paths to source files in debug info] > Date: Thu, 28 Feb 2008 22:01:42 -0500 > > On Feb 28, 2008, at 8:01 PM, Jay wrote: > > Are you all serious? Telling the debugger the full path to > source files via the debuginfo is bad? > What are the issues? I want to know so that when I use the > switch I know what trouble I'm bringing myself. > > Setting breakpoints in "modules", as .dll/.so files, is > unaffected I presume. > As is setting them by full name PosixProcess__WaitProcess. > That is what I "always" do ("always" as in, I just started using > gdb a few weeks ago). > > What I could imagine is affected is setting them by file and > line number. > Do people do that? I guess the gui wrappers do, but I assume > that'd still work. ? > Maybe it depends. I should try out xcode and ddd and such? > > Do people say like break foo.c:#123? And now I've made them use > a full path? > > > Yes, I do this all the time...via the emacs keybindings -- not sure > if full paths would break things or not. > > Gdb doesn't have any fuzzy matching? > > > Not sure. > > Maybe in gcc I can give multiple file names? > > > Again, not sure. > > This really greatly improves the out-of-the-box minimally > configured debugging experience. > Gdb automatically shows me the source as I step, instead of just > file name and line number. > cdb/windbg at least show disassembly by default, but gdb > doesn't, so by default gdb was showing hardly anything at all, > quite poor. I admit, I'm at the start of the learning curve on > gdb. I had to look to find the dir command. I had to look to > find display/x $pc. To use the dir command, I have to constantly > switch my slashes, since I get the paths from dir /s/b. > > > I use gdb under emacs... if the emacs bindings continue to work > then OK, but if not then problems. > > I will make it a switch in cm3 and cm3cg if it is really a problem. > > In C it is a common idiom: > void assert_failed(const char* condition, const char* file, > unsigned line); > #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, > __LINE__) : (void)0) > > __FILE__ can vary between "the parameter to the compiler on the > command line", or "full path", depending on implementation. > > Also: > printf("foo is %d in %s\n", foo, __FILE__). > > This really just seems like basic correctness to me, to give a > debugger full paths. > I'm quite surprised by the pushback. > > > I look forward to Rodney's input since he has most experience with > m3gdb and its expectations, and moreover with the current behavior > of gdb for other languages. > > Assertions I think should also be "fixed" further. And I suspect > "webinfo" but that could wait until Reactor is available.. > > - Jay > > > ------------------------------------------------------------------------ > >> From: hosking at cs.purdue.edu >> To: rodney.bates at wichita.edu >> Date: Thu, 28 Feb 2008 14:12:33 -0500 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: put full paths to source files in > debug info] >> >> I concur with Rodney on this. There are deeper issues here than >> simply avoiding the need to use dir in gdb. >> >> On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: >> >> > >> > I don't understand what the need for these paths is. In every >> > complete >> > program, all the interfaces and all the modules must have > unique >> > simple >> > names, otherwise code could not refer to them. With the > filename >> > matchup >> > rules, this should make all the simple file names unique > too. So any >> > debug commands should never need a path. And using simple names >> > avoids >> > the problems of moving compiled code. >> > >> > Is it more output from the debugger you want? If so, this > could no >> > doubt >> > be done by the debugger itself with the debug info as it > was. It >> > already >> > contained one copy of the full path to the source file in each >> > object file, >> > though I don't know of a place the debugger uses this now. >> > >> > Yes, I know the filename/modulename rules don't actually > apply for >> > modules, >> > but not following them is a bad practice. I've been around that >> > block many >> > times with Ada, and believe me, it's a nightmare. > Furthermore, then >> > you >> > wouldn't be able to name things in the debugger as >> > ModuleName.VarOrProcInModule, >> > This construct does not exist in code but is very useful in >> > debugging, especially >> > when InterfaceName/ModuleName is not one-to-one, e.g. when a > module >> > exports >1 >> > interface, etc. >> > >> > Jay wrote: >> >> truncated again! and possibly misformated.. >> >> >> >> > ------------------------------------------------------------------------ >> >> From: jayk123 at hotmail.com >> >> To: m3devel at elegosoft.com >> >> Subject: RE: put full paths to source files in debug info >> >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> >> pps: "webinfo" (Reactor?) and assertion failures are > affected by >> >> this also, but not fully. >> >> Before you would have gotten: >> >> *** >> >> *** runtime error: >> >> *** <*ASSERT*> failed. >> >> *** file "WaitProcessCygwin.m3", line 16 >> >> *** >> >> but now you get: >> >> *** >> >> *** runtime error: >> >> *** <*ASSERT*> failed. >> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> >> *** >> >> I'd say the realpath call (or whatever the portable Modula-3 >> >> library >> >> call is) should be moved up to m3front to address these, > and the >> >> parse.c change undone. >> >> As well, I believe resolving symlinks is happening too but >> >> that >> >> wasn't the point, so something instead of realpath might be >> >> preferable. Like, just see if the string starts ".\" or > "..\", it >> >> will almost always start "..\", and if so, prepend current > working >> >> directory and then workout the dots. >> >> It may also be reasonable to provide paths to the compiler >> >> to remove >> >> from the starts of paths, which would likely address the > symlink >> >> issue, since they are more likely to be nearer the start of > the >> >> path >> >> than the middle or end. As well as partly the >> >> privacy/size/same-across-machines issues. >> >> In any case, I think this easy small change is already very >> >> useful >> >> progress. Or does everyone else just fill up .gdbinit with dir >> >> commands? It seems to me that it shouldn't even that > difficult, >> >> even >> >> if it isn't very difficult. >> >> Agreed? >> >> - Jay >> >> >> >> > ------------------------------------------------------------------------ >> >> From: jayk123 at hotmail.com >> >> To: m3devel at elegosoft.com >> >> Subject: re: put full paths to source files in debug info >> >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> >> ps: does anyone care that binaries built from different cvs >> >> checkouts, but otherwise identical source, will no longer > match, >> >> unless perhaps they are "stripped"? >> >> If so, or if any of the other issues bug people, or any other >> >> problem is brought up or discovered, this can be made a command >> >> line option. I will always turn it on. :) >> >> - Jay >> >> >> >> > ------------------------------------------------------------------------ >> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> >> > To: m3commit at elegosoft.com >> >> > From: jkrell at elego.de >> >> > Subject: [M3commit] CVS Update: cm3 >> >> > >> >> > CVSROOT: /usr/cvs >> >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> >> > >> >> > Modified files: >> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> >> > Scanner.m3 >> >> > >> >> > Log message: >> >> > put full paths to source files in debug info >> >> > >> >> > This has the minor downsides of: >> >> > 1) grows the debug info (it is already huge; who is > counting?) >> >> > 2) reveals file system layout in debug info (privacy?) >> >> > 3) does it inhibit debugging files from other people's > machines >> >> or does gdb dir still work? >> >> > >> >> > but definitely makes for a more pleasant debugging > experience >> >> when >> >> > debugging stuff you have built yourself. >> >> > >> >> > The linear searching to see if a name has been allocated a >> >> number yet >> >> > will obviously slow way down due to a large increase in > common >> >> prefixes, >> >> > but that should be a hash table anyway. Linear search is > lame. >> >> > (or a trie, but working from the ends of the strings, > minus the >> >> last one or few >> >> > characters, due to common prefixes as well as common > suffixes) >> >> > >> >> > Note that both m3front and m3cc changes are needed as > m3front >> >> has >> >> paths >> >> > relative to the current working directory or such. >> >> > >> >> > For most packages, you can get by without the m3front change >> >> and >> >> just prepend >> >> > "../src/" to the path in m3cc, but that doesn't work for >> >> hierarchical packages >> >> > such as libm3 and m3core which I am debugging. >> >> > ------------------------------------------------------------------------ >> >> Need to know the score, the latest news, or you need your > Hotmail?- >> >> get your "fix". Check it out. > > >> > >> > >> > -- >> > ------------------------------------------------------------- >> > 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 >> > > > ------------------------------------------------------------------------ > Need to know the score, the latest news, or you need your > Hotmail?-get your "fix". Check it out. > > > > > ------------------------------------------------------------------------ > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > -- ------------------------------------------------------------- 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 dragisha at m3w.org Fri Feb 29 18:20:35 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 29 Feb 2008 18:20:35 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C83637.6010602@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> Message-ID: <1204305635.13580.82.camel@hias.m3w.org> On Fri, 2008-02-29 at 10:43 -0600, Rodney M. Bates wrote: > m3gdb needs work on threads. I have never done anything on it. > Unless Tony did some when he was working on it several years ago, > I think it is pretty much as it came from SRC, and that was fairly > primitive. Plus, the new pthreads implementation is not supported. > Once I glanced at the code and it looked immediately like what was > there would not work at all. This has been on my list a while. "Stock" gdb does support pthreads. Is that not enough for m3gdb? As for former M3 threads, msgdb had patches to go through thread lists, and many things more. As current implementation has no such kind of control over threads, I see no point in pursuing anything similar to what was before. > > > > > If you want to try anything on FreeBSD, let me know, I can provide > > a remote login. > > Yes, that would be helpful. > > > > > Olaf > -- Dragi?a Duri? From hosking at cs.purdue.edu Fri Feb 29 18:46:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 12:46:07 -0500 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C83637.6010602@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> Message-ID: m3gdb should probably avoid any specific reliance on the particular threads implementation. If using pthreads, then gdb already has support for that (I frequently debug threads issues for CM3 using the regular gdb without any problems). If using SIGVTALRM threads then I would suggest that users will need to be familiar with the thread scheduling points that it uses (triggered by SIGVTALRM, and implemented by Thread.Transfer). Since there is no way for m3gdb to "switch" contexts for SIGVTALRM threads then it really might as well be agnostic about threads generally. In summary, there should not be need for *special* support for threads in m3gdb. 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 Feb 29, 2008, at 11:43 AM, Rodney M. Bates wrote: > > > Olaf Wagner wrote: >> Quoting "Rodney M. Bates" : >>> As for other platforms, I don't have any around, and I'm not aware >>> of anybody >>> trying it. >> It compiles without problems on FreeBSD 6.3 and works as long as >> programs are linked with libthr.so (not with libpthread.so). > > Any more information on what the difference in these libraries is? > >> I haven't used it much yet, and some things seemed to be strange; >> thread stack switching or viewing didn't work at all. > > m3gdb needs work on threads. I have never done anything on it. > Unless Tony did some when he was working on it several years ago, > I think it is pretty much as it came from SRC, and that was fairly > primitive. Plus, the new pthreads implementation is not supported. > Once I glanced at the code and it looked immediately like what was > there would not work at all. This has been on my list a while. > >> If you want to try anything on FreeBSD, let me know, I can provide >> a remote login. > > Yes, that would be helpful. > >> Olaf > > -- > ------------------------------------------------------------- > 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 Fri Feb 29 18:46:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 12:46:49 -0500 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204305635.13580.82.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> Message-ID: <37E0E1B4-710C-4A1D-B42F-380E14451D5F@cs.purdue.edu> Precisely! 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 Feb 29, 2008, at 12:20 PM, Dragi?a Duri? wrote: > On Fri, 2008-02-29 at 10:43 -0600, Rodney M. Bates wrote: >> m3gdb needs work on threads. I have never done anything on it. >> Unless Tony did some when he was working on it several years ago, >> I think it is pretty much as it came from SRC, and that was fairly >> primitive. Plus, the new pthreads implementation is not supported. >> Once I glanced at the code and it looked immediately like what was >> there would not work at all. This has been on my list a while. > > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > > As for former M3 threads, msgdb had patches to go through thread > lists, and many things more. As current implementation has no such > kind > of control over threads, I see no point in pursuing anything similar > to > what was before. > >> >>> >>> If you want to try anything on FreeBSD, let me know, I can provide >>> a remote login. >> >> Yes, that would be helpful. >> >>> >>> Olaf >> > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 29 19:27:51 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 29 Feb 2008 13:27:51 -0500 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: <47C83CC7.9060905@wichita.edu> References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <47C83CC7.9060905@wichita.edu> Message-ID: On Feb 29, 2008, at 12:11 PM, Rodney M. Bates wrote: > > > Jay wrote: >> Are you all serious? Telling the debugger the full path to source >> files via the debuginfo is bad? > > Below. > >> What are the issues? I want to know so that when I use the switch I >> know what trouble I'm bringing myself. >> Setting breakpoints in "modules", as .dll/.so files, is unaffected >> I presume. >> As is setting them by full name PosixProcess__WaitProcess. > > In m3gdb, you can also say PosixProcess.WaitProcess. > >> That is what I "always" do ("always" as in, I just started using >> gdb a few weeks ago). >> What I could imagine is affected is setting them by file and line >> number. >> Do people do that? I guess the gui wrappers do, but I assume that'd >> still work. ? >> Maybe it depends. I should try out xcode and ddd and such? >> Do people say like break foo.c:#123? And now I've made them use a >> full path? > > Yes. PosixProcess.m3:123 is the normal way. Since source file > simple names > are unique, this is enough in Modula-3. I suppose in C, if somebody > actually > had >1 source file with the same simple name, something messier > would be > needed, but normally, break Foo.c:123 is the way to do it. > > Likewise, before your change to debug info, output from (m3)gdb > showing where > something is stopped uses source file simple names and line numbers > too. > >> Gdb doesn't have any fuzzy matching? >> Maybe in gcc I can give multiple file names? >> This really greatly improves the out-of-the-box minimally >> configured debugging experience. >> Gdb automatically shows me the source as I step, instead of just >> file name and line number. >> cdb/windbg at least show disassembly by default, but gdb doesn't, >> so by default gdb was showing hardly anything at all, quite poor. I >> admit, I'm at the start of the learning curve on gdb. I had to look >> to find the dir command. I had to look to find display/x $pc. To >> use the dir command, I have to constantly switch my slashes, since >> I get the paths from dir /s/b. > > The paths to source are used in (m3)gdb only to display a portion of > actual > source code, not to identify file/line# places. For the former > function only, > (m3)gdb has to have full paths, and they must be as they may have > changed since > things were compiled/linked. I put -d command line options for all my > source file paths (which do the same thing as dir gdb commands) in a > startup > file for any project that gets significant work. > > I do agree, it would be nice for a quick jump into a debugger, not > to have > to do this. It could only work, of course, if the source files are > where > they were at the time of compilation. The way to do this is for gdb > to > try the path from the object module, after normal use of dir/-d > paths have > failed. Since we can't change gdb, this would only be in m3gdb. Indeed! Given that cm3 compiles in one location and ships to another it is important that full paths *not* be used I suspect. That way, one can have users of installed packages debug against their source as necessary. > On big advantage of this would be that it would work when one needs to > debug right into the runtime system, as I do somewhat regularly. That > requires several additional paths that one would not ordinarily have > specified. The way we are installing Modula-3 now, it is a pretty > safe > bet that, if the source exists at all, then it where it was when the > runtime system was compiled. > > (Well, copies of the interfaces do get placed in the install > directory, but > I'm not sure m3gdb ever displays non-executable code, which is all > that interfaces have.) > > You have convinced me to add this to my list. > >> I will make it a switch in cm3 and cm3cg if it is really a problem. >> In C it is a common idiom: >> void assert_failed(const char* condition, const char* file, >> unsigned line); >> #define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, >> __LINE__) : (void)0) >> > > We don't have anything like __FILE__ and __LINE__ in Modula-3. I > have a > largish program full of assertions with it's own coded assertion > handling, > including recoverable (in a sense, roll back to a consistent state) > assertion > failures. It could use something like this. But it also seems > pretty hackish > to me too. Sure we do: Compiler.ThisLine() Compiler.ThisFile() > > >> __FILE__ can vary between "the parameter to the compiler on the >> command line", or "full path", depending on implementation. >> Also: >> printf("foo is %d in %s\n", foo, __FILE__). >> This really just seems like basic correctness to me, to give a >> debugger full paths. > > People can and often do move executables to different machines and > also > sometimes move source trees around on the original machine. Using > simple > file names within an executable (of which there is always exactly one) > is invariant to all this, and a lot shorter to type/read. Agreed. > > >> I'm quite surprised by the pushback. >> Assertions I think should also be "fixed" further. And I suspect >> "webinfo" but that could wait until Reactor is available.. >> - Jay >> ------------------------------------------------------------------------ >> > From: hosking at cs.purdue.edu >> > To: rodney.bates at wichita.edu >> > Date: Thu, 28 Feb 2008 14:12:33 -0500 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] FW: put full paths to source files in >> debug info] >> > >> > I concur with Rodney on this. There are deeper issues here than >> > simply avoiding the need to use dir in gdb. >> > >> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote: >> > >> > > >> > > I don't understand what the need for these paths is. In every >> > > complete >> > > program, all the interfaces and all the modules must have unique >> > > simple >> > > names, otherwise code could not refer to them. With the filename >> > > matchup >> > > rules, this should make all the simple file names unique too. >> So any >> > > debug commands should never need a path. And using simple names >> > > avoids >> > > the problems of moving compiled code. >> > > >> > > Is it more output from the debugger you want? If so, this could >> no >> > > doubt >> > > be done by the debugger itself with the debug info as it was. It >> > > already >> > > contained one copy of the full path to the source file in each >> > > object file, >> > > though I don't know of a place the debugger uses this now. >> > > >> > > Yes, I know the filename/modulename rules don't actually apply >> for >> > > modules, >> > > but not following them is a bad practice. I've been around that >> > > block many >> > > times with Ada, and believe me, it's a nightmare. Furthermore, >> then >> > > you >> > > wouldn't be able to name things in the debugger as >> > > ModuleName.VarOrProcInModule, >> > > This construct does not exist in code but is very useful in >> > > debugging, especially >> > > when InterfaceName/ModuleName is not one-to-one, e.g. when a >> module >> > > exports >1 >> > > interface, etc. >> > > >> > > Jay wrote: >> > >> truncated again! and possibly misformated.. >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> From: jayk123 at hotmail.com >> > >> To: m3devel at elegosoft.com >> > >> Subject: RE: put full paths to source files in debug info >> > >> Date: Thu, 28 Feb 2008 08:44:11 +0000 >> > >> pps: "webinfo" (Reactor?) and assertion failures are affected by >> > >> this also, but not fully. >> > >> Before you would have gotten: >> > >> *** >> > >> *** runtime error: >> > >> *** <*ASSERT*> failed. >> > >> *** file "WaitProcessCygwin.m3", line 16 >> > >> *** >> > >> but now you get: >> > >> *** >> > >> *** runtime error: >> > >> *** <*ASSERT*> failed. >> > >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16 >> > >> *** >> > >> I'd say the realpath call (or whatever the portable Modula-3 >> > >> library >> > >> call is) should be moved up to m3front to address these, and the >> > >> parse.c change undone. >> > >> As well, I believe resolving symlinks is happening too but >> > >> that >> > >> wasn't the point, so something instead of realpath might be >> > >> preferable. Like, just see if the string starts ".\" or "..\", >> it >> > >> will almost always start "..\", and if so, prepend current >> working >> > >> directory and then workout the dots. >> > >> It may also be reasonable to provide paths to the compiler >> > >> to remove >> > >> from the starts of paths, which would likely address the symlink >> > >> issue, since they are more likely to be nearer the start of the >> > >> path >> > >> than the middle or end. As well as partly the >> > >> privacy/size/same-across-machines issues. >> > >> In any case, I think this easy small change is already very >> > >> useful >> > >> progress. Or does everyone else just fill up .gdbinit with dir >> > >> commands? It seems to me that it shouldn't even that difficult, >> > >> even >> > >> if it isn't very difficult. >> > >> Agreed? >> > >> - Jay >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> From: jayk123 at hotmail.com >> > >> To: m3devel at elegosoft.com >> > >> Subject: re: put full paths to source files in debug info >> > >> Date: Thu, 28 Feb 2008 08:31:32 +0000 >> > >> ps: does anyone care that binaries built from different cvs >> > >> checkouts, but otherwise identical source, will no longer match, >> > >> unless perhaps they are "stripped"? >> > >> If so, or if any of the other issues bug people, or any other >> > >> problem is brought up or discovered, this can be made a command >> > >> line option. I will always turn it on. :) >> > >> - Jay >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> > Date: Thu, 28 Feb 2008 09:23:22 +0000 >> > >> > To: m3commit at elegosoft.com >> > >> > From: jkrell at elego.de >> > >> > Subject: [M3commit] CVS Update: cm3 >> > >> > >> > >> > CVSROOT: /usr/cvs >> > >> > Changes by: jkrell at birch. 08/02/28 09:23:22 >> > >> > >> > >> > Modified files: >> > >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> > >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3 >> > >> > Scanner.m3 >> > >> > >> > >> > Log message: >> > >> > put full paths to source files in debug info >> > >> > >> > >> > This has the minor downsides of: >> > >> > 1) grows the debug info (it is already huge; who is counting?) >> > >> > 2) reveals file system layout in debug info (privacy?) >> > >> > 3) does it inhibit debugging files from other people's >> machines >> > >> or does gdb dir still work? >> > >> > >> > >> > but definitely makes for a more pleasant debugging experience >> > >> when >> > >> > debugging stuff you have built yourself. >> > >> > >> > >> > The linear searching to see if a name has been allocated a >> > >> number yet >> > >> > will obviously slow way down due to a large increase in common >> > >> prefixes, >> > >> > but that should be a hash table anyway. Linear search is lame. >> > >> > (or a trie, but working from the ends of the strings, minus >> the >> > >> last one or few >> > >> > characters, due to common prefixes as well as common suffixes) >> > >> > >> > >> > Note that both m3front and m3cc changes are needed as m3front >> > >> has >> > >> paths >> > >> > relative to the current working directory or such. >> > >> > >> > >> > For most packages, you can get by without the m3front change >> > >> and >> > >> just prepend >> > >> > "../src/" to the path in m3cc, but that doesn't work for >> > >> hierarchical packages >> > >> > such as libm3 and m3core which I am debugging. >> > >> >> ------------------------------------------------------------------------ >> > >> Need to know the score, the latest news, or you need your >> Hotmail?- >> > >> get your "fix". Check it out. > > >> > >> > > >> > > -- >> > > ------------------------------------------------------------- >> > > 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 >> > >> ------------------------------------------------------------------------ >> Need to know the score, the latest news, or you need your Hotmail?- >> get your "fix". Check it out. > > > > -- > ------------------------------------------------------------- > 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 rodney.bates at wichita.edu Fri Feb 29 22:09:47 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 15:09:47 -0600 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <1204305635.13580.82.camel@hias.m3w.org> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> Message-ID: <47C8749B.6070101@wichita.edu> Do you know if this pthread support was in by gdb 6.4? Dragi?a Duri? wrote: > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Fri Feb 29 22:18:53 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 29 Feb 2008 15:18:53 -0600 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> <47C83CC7.9060905@wichita.edu> Message-ID: <47C876BD.10003@wichita.edu> Tony Hosking wrote: >> We don't have anything like __FILE__ and __LINE__ in Modula-3. I have a >> largish program full of assertions with it's own coded assertion >> handling, >> including recoverable (in a sense, roll back to a consistent state) >> assertion >> failures. It could use something like this. But it also seems >> pretty hackish >> to me too. > > > Sure we do: > > Compiler.ThisLine() > Compiler.ThisFile() > Thank you. I didn't know about these. -- ------------------------------------------------------------- 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 mika at async.caltech.edu Fri Feb 29 22:19:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 29 Feb 2008 13:19:43 -0800 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: Your message of "Fri, 29 Feb 2008 11:11:35 CST." <47C83CC7.9060905@wichita.edu> Message-ID: <200802292119.m1TLJhcB080697@camembert.async.caltech.edu> "Rodney M. Bates" writes: ... >People can and often do move executables to different machines and also >sometimes move source trees around on the original machine. Using simple >file names within an executable (of which there is always exactly one) >is invariant to all this, and a lot shorter to type/read. ... Arbitrary paths are also not trustworthy on many Unix systems that run automounters. The path you get from getcwd is likely not to be permanently accessible on those. (You access the files via a different path.) Mika From hendrik at topoi.pooq.com Fri Feb 29 23:41:26 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 29 Feb 2008 17:41:26 -0500 Subject: [M3devel] random-acces I/O Message-ID: <20080229224126.GA21397@topoi.pooq.com> I need to do direct-access I/O from a Modula 3 program with a file format that is externally specified. It is necessary to both read and write in random fashion during a run of the program, prefereably without having to close or open the file each time. I expect the answers to the following questions are "Yes", but I'd appreciate confirmation: ? If I have a File.T (obtained from FS.OpenFile) can I have both a Rd.T and a Wr.T active on it simultaeously? ? Will things written using the Wr.T be immediately available for reading with the Rd.T, with no buffereing problems? ? Are there methods for locking the file -- or portions of it -- against simutaneous access by other programs, including ones written in other languages? -- hendrik From dragisha at m3w.org Fri Feb 29 23:09:11 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 29 Feb 2008 23:09:11 +0100 Subject: [M3devel] state of m3gdb on LINUXLIBC6? In-Reply-To: <47C8749B.6070101@wichita.edu> References: <1204226001.13580.64.camel@hias.m3w.org> <47C749B8.1060906@wichita.edu> <20080229011936.fs7gutizgggg8s44@mail.elegosoft.com> <47C83637.6010602@wichita.edu> <1204305635.13580.82.camel@hias.m3w.org> <47C8749B.6070101@wichita.edu> Message-ID: <1204322951.13580.87.camel@hias.m3w.org> I think it's in since 6.0 at least. And maybe even as war as 4.17. I am using, when debugging threads, only gdb commands. And it, sort of, works... I still have to try debugger seriously. dd On Fri, 2008-02-29 at 15:09 -0600, Rodney M. Bates wrote: > Do you know if this pthread support was in by gdb 6.4? > > Dragi?a Duri? wrote: > > "Stock" gdb does support pthreads. Is that not enough for m3gdb? > > -- Dragi?a Duri? From jayk123 at hotmail.com Thu Feb 7 05:08:04 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 07 Feb 2008 04:08:04 -0000 Subject: [M3devel] Latest parse.c In-Reply-To: References: Message-ID: >> I don't think it "quits" for us, but worth the printf'ing and such. >> like Sleep(int,record,int,record); >> I wouldn't be surprised if you get @16, but I'm placing no bets here. :) confirmed. Wish I had more to report by now.. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Tue Feb 12 04:29:30 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 12 Feb 2008 03:29:30 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> Message-ID: <47B1168F.8020302@wichita.edu> It sounds like all that Mac OS X needs is for _all_ types in an entire program to use the liberal packing rules. Have I understood correctly? I would have no grief over that. Darko wrote: > The liberalised alignment rules are required for the native Mac OS X > API and should stay. You cannot use that API without them. I think the > pragma is not required and can be removed. I agree with all the points > you make. The effect of the modified alignment rules it to allow > *packed* structures to have members aligned on byte boundaries. This > has the effect of packing the fields in the tightest arrangement > allowed by the platform. This might affect performance, but if the user > is concerned about this they should specify field bit sizes that > deliver improved performance. I don't see a need to specify this on a > structure level, for the reasons you give and because the difference > isn't significant enough in the case of packed structures and their > physical layout and restrictions are platform dependent anyway. > > I might also add that the alignment code is currently broken on > I386_DARWIN. > > - Darko > > > On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > >> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >> being used anywhere? >> >> It is not documented in pragmas.html. The compiler front end appears >> to accept it. (In fact, Decls.m3 contains constants that suggest >> limitations on what declarations the pragma can appear on, but these >> are not actually enforced.) It liberalizes the alignment rules, >> generally allowing scalars to start on any byte boundary. >> >> Pickles have to be able to reconstruct the layout of types as the >> compiler would have done it for a machine (on which a now-being-read >> pickle was written) with different word size and alignment properties. >> Currently, pickles are completely unaware of lazy alignment. It >> would have to be encoded in type descriptions generated by the compiler >> using TipeDesc and read by pickles using RTTipe. >> >> Most troubling to me is what looks like a linguistic Pandora's box. >> The pragma can be associated with any constant, variable, or type >> _declaration_ (not type definition), with the result that different >> values of the same type can actually be different in their alignment >> rules and thus their layout. Similarly for different identifiers >> equated to the same type. Although the effects of this could possibly >> be hidden from the programmer in purely safe code, not so with unsafe >> code. I haven't thoroughly thought this through, but seems to me to >> really fly in the face of the whole typing philosophy of the language. >> >> For example, if pickles were to read in an object value, and there >> were >1 variants of the object's type in the reading program, differing >> only in the alignment rules, how would it decide which one to build? >> In fact, ignoring pickles altogether and just looking at a single >> program, >> if the object's type doesn't actually uniquely give its memory layout, >> how can it be accessed correctly? >> >> Additionally, a quick look at the compiler suggests it won't generate >> correct code for whole record assignment when the LHS and RHS are the >> same type but have different alignment characteristics. >> >> The more I think about it, it seems the only workable possibilities are: >> >> 1) Require the pragma to be associated only with a type _definition_ >> not a >> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make this a >> property of the type that propagates to all names for the type and >> all variables, constants, etc. Also, this would make this property >> a part of the type signature that pickles uses when reading, -OR- >> >> 2) Forget it altogether. >> >> What do people think? >> -- >> ------------------------------------------------------------- >> 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 > > > -- ------------------------------------------------------------- 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 darko at darko.org Wed Feb 13 03:20:56 2008 From: darko at darko.org (Darko) Date: Wed, 13 Feb 2008 02:20:56 -0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: <53857.165.228.199.218.1202868771.squirrel@webmail.darko.org> Possibly, but it's a worthy goal. M3 should be deployable on any platform. Too much of the discussion lately seems to be tieing the language to particular platforms, we should be pushing the other way. I'm insterested in working toward a distribution which has no platform APIs, only native M3 interfaces with native strings, traced references only and range checked and enumaterated everything. We should be looking to absact away C interfaces at a low level, not permeate upwards. > My principle concern is that once we provide C APIs then C will > permeate the M3 space more pervasively (both apps and libraries). > What happens when I want to bring up a system where there is no > C?!?! Consider the SPIN OS perhaps... > > Maybe I am just being overly fusty... > > On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > >> What we _maybe_ can do... is to make some special, preprocessable >> source >> form, which some quake command can parse into multiple files in their >> folders. And these file can be compiled later...Kind of how generic >> works. >> >> But, as current system works, and it does it very well, and as only >> case >> where we really need this is Windows... most Unices being or becoming >> POSIX... I don't see it's smart to spend resources on becoming more >> C... >> Esp when "founding fathers" made it so good and so much non-C :). >> >> If we really need to make some approach to "their world", it's much >> better to work on interoperability issues and thus cement our >> first-class-citizen language status even more. >> >> dd >> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >>> Jay: >>> >>> My understanding of Modula-3 is that rather than cluttering up the >>> source code with a bunch of preprocessor directives to deal with the >>> various changes needed by various platforms, a separate source >>> file is >>> used for platforms whose implementation must diverge. The m3makefile >>> is used to control the selection of these platform sources at build >>> time. I like this approach much better. >>> >>> Regards, >>> Randy >>> >>>>>> Jay 2/11/2008 8:21 PM >>> >>> So I have NOT thought this through. >>> >>> I wonder if "preprocessing" dependent only on "target" is a good >>> idea. >>> >>> Something like either the ability to prefix pragmas with a target, or >>> an "iftarget" and "ifnottarget" pragma. >>> >>> Something like so: >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> It's a small can of worms. >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an >>> interface/module). >>> >>> What about IF_OSTYPE? >>> What about expressions? >>> IF_TARGET NT386 OR NTAMD64 >>> >>> IF_TARGET STARTS(NT) >>> >>> etc. >>> >>> I don't really have enough interest here to work through this, just >>> sending out the bait... >>> >>> Obviously this was triggered by my happening into the odbc directory >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >>> conventions with a target. >>> >>> This reminds me of an important point here however -- nobody else is >>> going to make the mistake of ever having multiple calling >>> conventions. >>> Therefore the generality of prefixing WINAPI with NT386: is useless. >>> Unless Mac68K support is added. >>> >>> And here is some rationale even. The PC and Mac evolved from "small" >>> systems, where assembly programming was common, more people knew more >>> lower level details and playing games with calling conventions was >>> something anyone could do. Most other current systems are rooted in C >>> programming. Working in C, calling conventions are generally in a >>> hidden layer below what anyone thinks about. Therefore, the smaller >>> number of capable people working at that level have the good sense to >>> only have one calling convention. No more systems will evolve from >>> "small", at least not without having observed this history. >>> Therefore, >>> there will no longer be multiple calling conventions. >>> >>> That is my theory at least. >>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >>> only x86 >> -- >> Dragi??a Duri?? > > From dabenavidesd at yahoo.es Thu Feb 14 05:56:08 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 14 Feb 2008 04:56:08 -0000 Subject: [M3devel] Modula-3 discussions In-Reply-To: Message-ID: <855460.51998.qm@web27107.mail.ukl.yahoo.com> Hi all: I think that all humans sometimes make mistakes (specially me :), is up to us try to solve them in the best way (I also think there is only one way). I think I don't have enough patience to read the multiple emails Jay write some inspired days (believe me I sometimes don't like to see so many mails from the list even if they are written by Jay or not), however if I am considered and fraternal with all of you I must read it and if I can make some input/comment is a very good think to do it, I think they are very convenient, so for the purpose of a better arguing why we don't try to stay calm and try to understand that the comments of other people are valuable as our opinions are, and learn something important: hear other's opinions. I understand that in a free software project there is always a leader, a head or a principal, maybe this is clear to some of you, but also there are others whom want to make inputs to the development of the project. So two discussions are very clear in the m3devel lasts posts: some of us like more C, some of us like more other languages and some of us like Modula3 as it is, but that doesn't imply that we must change our way of thinking just because we don't agree with some other opinions and the way of continue cm3 development (but we also can question ourselves). We do use the mail for several good purposes but sometimes we forget a important issue: we are saying things to rest of the world that has access to this list, we are trying to get people more involved with the language environment and we don't want to loose users or developers, so it just doesn't matter if we agree with all the opinions of them (I remember one user in the m3devel list some time ago wrote that he has some code and he want to publish it, but I can't fin id it at the moment). I would like to know if It is very rare to try to migrate some part of the programming languages discussion on comp.lang.modula3 and the rest of the most related with cm3 development in m3devel list. Also if we have enough users to try to organize a Modula-3 user group meeting . For instance I know recent research work made by Laszlo Boeszoermenyi, I also can say that in our University (http://www.unal.edu.co) have been deloped in the last 7 years two projects with Modula-3 (one of control and automatization and one of cgi programming), also it was dictated several courses using Modula-3 (there is a set of slides that it's not published yet based on Laszlo's book, I hope this can be give to community if it is important). Why don't try to spend some time making an index of such academic or research and commercial projects, people and institutions towards the benefit of the language developers and it's users. It existed on Michael Dagenais old m3 site a list of modula-3 contributors and enthusiasts: http://web.archive.org/web/20020326115358/http://m3.polymtl.ca/m3/faq/who/ I don't know if it exists on elego source tree tough Also update the acknowledgements of this url: http://modula3.elegosoft.com/pm3/pkg/intro/src/ack.html Well, I almost finishing this "inspired" email, I hope you enjoyed as me :) Thanks you for all the discussion :) and work. --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Feb 15 04:46:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 03:46:43 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> Message-ID: <47B50EDF.8060807@wichita.edu> 1) RTPacking.T and needs to have a separate size for LONGINT, (which can vary independently of the size of INTEGER). 2) Variable length values of subrange bounds found in type descriptions (in TipeDesc.i3) can now have values beyond what the native word size can represent. 3) RTType.Kind.Longint (which I presume you, Tony, added recently) is not handled by Pickles. I have done some coding on this, but have been interrupted. Tony Hosking wrote: > Why is LONGINT for pickles not yet supported? > -- ------------------------------------------------------------- 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 ronny.forberger at elegosoft.com Mon Feb 18 09:37:59 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Mon, 18 Feb 2008 08:37:59 -0000 Subject: [M3devel] Just a mailing list test Message-ID: <20080218093759.x4hxlv3m884wo0s8@mail.elegosoft.com> Please ignore. Ronny -- 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 mika at async.caltech.edu Tue Feb 19 00:09:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 18 Feb 2008 23:09:47 -0000 Subject: [M3devel] code submission In-Reply-To: Your message of "Mon, 18 Feb 2008 19:50:20 GMT." Message-ID: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> That's right, that's approximately what it does. More succinctly, like this :) t.tab : REF ARRAY OF RECORD value : Value.T; next : INTEGER := 0 END; PROCEDURE Get(t : T; READONLY k : ARRAY OF Key.T) : Value.T = VAR p := 0; BEGIN FOR i := FIRST(k) TO LAST(k) DO WITH next = t.tab[p][k[i]].next DO IF next = 0 THEN RETURN t.defValue (* not found *) ELSE p := next END END END; RETURN t.tab[p][k[LAST(k)]].value END Get; Knuth section 6.3 talks about it; he claims the word is based on "information reTRIEval". Tries can be faster than hash methods when most of the words are not to be found in the dictionary, and you can tell by reading just one or two characters that you don't have that word. Parsing a data file in the way what I am doing is an example: I am only interested in a very small subset of the lines. (The application is, given the complete data set for the Toronto Stock Exchange for a month, extract certain records pertaining to a small subset of stock tickers.) Of course, which tickers it is changes all the time, so you can't really compile in a special-case switch statement either. In my application, using the standard Modula-3 TEXT and Text.Hash, plus Text<>Tbl was many times slower than AWK. The trie code is quite a bit faster (completely limited by disk speed). Mika Jay writes: >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >aka "prefix tree" >if I want to recognize the strings, foo, food, fudge, and bar >look at the first character > if it is 'b', go ahead and compare to bar (or the tail to "ar") > if it is 'f' > look at the second character > if it is 'u', go ahead and compare to "fudge" (or the tail to "dge") > if it 'o' > compare the third character > and so on >=20 >Whether or not the data "stops" at unique prefixes is an implementation det= >ail. >If it does, the leaves can contain the entire string or just the tail. >I've fiddled with generating large nested switch statements from a list of = >strings. >I noticed there are many optimizations you can make. >Of course, first you check the length. >Then, really, instead of progressing from left to right, you can pick out c= >haracters with a higher switching factor. >For example if I have the strings foof and food, just look at the last char= >acter. >=20 >As well a hash based algorithm is probably best. >Precompute the hashes of all the strings. >Sor them. >Hash your input string. >Binary search for the hash. >And the compare for an exact match. >=20 >If you are going to do the final compare anyway, then you are going to touc= >h the whole string anyway, you might as well hash it and do a binary search= > I think. Make sure the hash function is fast of course, and not "perfect". >=20 > - Jay >=20 > > > >> Date: Mon, 18 Feb 2008 20:35:36 +0100> From: wagner at elegosoft.com> To: mi= >ka at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cod= >e submission> > Quoting Mika Nystrom :> > > Hello e= >veryone,> >> > I was looking at some code I've written and realized that I = >have a> > very small piece of tested code that may be of interest to other>= > > Modula-3 users. It's a generic "trie" that I coded a few years> > ago. D= >oes anyone have an opinion on adding it to cm3? Where, if so?> >> > http://= >www.async.caltech.edu/~mika/trie/> >> > It's useful for parsing; if you're = >parsing a language with longish> > keywords it is many times faster to use = >this structure and ARRAY> > OF CHAR than using the standard hash tables wit= >h TEXTs. (I developed> > it to parse an old "punch-card", i.e., 80-characte= >r fixed-width> > records, format for financial data.)> > Of course we could= > add this as a small package to m3-libs, or> even to libm3 (it looks rather= > small).> > I hate to sound so uneducated, but what exactly does `trie' sta= >nd for?> It's not contained in my favourite online dictionary either.> > Ol= >af> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-A= >llee 25 / Geb=E4ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mo= >bile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | = >Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgerich= >t Charlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >aka "prefix tree"

>if I want to recognize the strings, foo, food, fudge, and bar
>look at the first character
>  if it is 'b', go ahead and compare to bar (or the tail to "ar")
>  if it is 'f'
>   look at the second character
>     if it is 'u', go ahead and compare to "fudge" (or = >the tail to "dge")
>     if it 'o'
>        compare the third character
>        and so on
> 
>Whether or not the data "stops" at unique prefixes is an implementation det= >ail.
>If it does, the leaves can contain the entire string or just the tail.
>
I've fiddled with generating large nested switch statements from a list= > of strings.
>I noticed there are many optimizations you can make.
>Of course, first you check the length.
>Then, really, instead of progressing from left to right, you can pick out c= >haracters with a higher switching factor.
>For example if I have the strings foof and food, just look at the last char= >acter.
> 
>As well a hash based algorithm is probably best.
>Precompute the hashes of all the strings.
>Sor them.
>Hash your input string.
>Binary search for the hash.
>And the compare for an exact match.
> 
>If you are going to do the final compare anyway, then you are going to touc= >h the whole string anyway, you might as well hash it and do a binary search= > I think. Make sure the hash function is fast of course, and not "perfect".= >
> 
> - Jay
> 
> >
>
>> Date: Mon, 18 Feb 2008 20:35:36 +0100
> From: wagner at elegosoft.c= >om
> To: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
= >> Subject: Re: [M3devel] code submission
>
> Quoting Mika N= >ystrom <mika at async.caltech.edu>:
>
> > Hello everyone= >,
> >
> > I was looking at some code I've written and rea= >lized that I have a
> > very small piece of tested code that may b= >e of interest to other
> > Modula-3 users. It's a generic "trie" t= >hat I coded a few years
> > ago. Does anyone have an opinion on ad= >ding it to cm3? Where, if so?
> >
> > http://www.async.ca= >ltech.edu/~mika/trie/
> >
> > It's useful for parsing; if= > you're parsing a language with longish
> > keywords it is many ti= >mes faster to use this structure and ARRAY
> > OF CHAR than using = >the standard hash tables with TEXTs. (I developed
> > it to parse = >an old "punch-card", i.e., 80-character fixed-width
> > records, f= >ormat for financial data.)
>
> Of course we could add this as = >a small package to m3-libs, or
> even to libm3 (it looks rather small= >).
>
> I hate to sound so uneducated, but what exactly does `t= >rie' stand for?
> It's not contained in my favourite online dictionar= >y either.
>
> Olaf
>
>
>
> --
&= >gt; Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee= > 25 / Geb=E4ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96= > mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegos= >oft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelreg= >ister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>= >


Connect and share in new ways with Windows Live. ef=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelif= >e_012008' target=3D'_new'>Get it now! >= > >--_2d3a5c15-3dde-48d1-aca8-ba60da1724e8_-- From wagner at elegosoft.com Tue Feb 19 00:30:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 23:30:50 -0000 Subject: [M3devel] code submission In-Reply-To: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> References: <200802182304.m1IN48ET039494@camembert.async.caltech.edu> Message-ID: <20080219003049.nmeda2ky8880ksss@mail.elegosoft.com> Quoting Mika Nystrom : > Knuth section 6.3 talks about it; he claims the word is based on > "information reTRIEval". Tries can be faster than hash methods > when most of the words are not to be found in the dictionary, and > you can tell by reading just one or two characters that you don't > have that word. Parsing a data file in the way what I am doing is > an example: I am only interested in a very small subset of the > lines. (The application is, given the complete data set for the > Toronto Stock Exchange for a month, extract certain records pertaining > to a small subset of stock tickers.) Of course, which tickers it > is changes all the time, so you can't really compile in a special-case > switch statement either. > In my application, using the standard Modula-3 TEXT and Text.Hash, > plus Text<>Tbl was many times slower than AWK. The trie code is quite > a bit faster (completely limited by disk speed). OK, thanks for the explanations. I should have a look at the old standard books more often. I know prefix trees, but had never heard the term `trie'. I think we should definitely add it. I'm still not sure if it should go better into its own package or into the generics part of libm3. What do the others 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 darko at darko.org Tue Feb 19 01:32:07 2008 From: darko at darko.org (Darko) Date: Tue, 19 Feb 2008 00:32:07 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> <489B2E3B-CE85-49EC-9DD6-7642FFDBD1B6@cs.purdue.edu> Message-ID: <13213.165.228.199.218.1203380790.squirrel@webmail.darko.org> We seem to be going through these same point several times. I'm not sure what the difficulty is, I'm just repeating myself. Keep in mind this applies *only* to packed structures, ie BIT FOR or bit fields. The change I put in libralised the *M3* alignment rules so that BITS FOR fields in structures would align on byte boundries if possible instead of restricting them to word alignment generally. GCC happily generates code for this. There may be restrictions in GCC's C as to how you can arrange bit fields but I don't see what they have to do with M3. This is absolutely essentail for using the native APIs on Mac OS X and its removal would make M3 pointless for use on the Mac, at least more me. This should be the default behviour. If you are using BITS FOR it's becuase you want to arrange the fields in a record in particular way. Why then arbitrarliy pad out the fields? If performance is an issue, the user should be using appropriate field bit sizes. The implementation rule for BITS FOR in M3 is implementation dependent, there are no language issues. The LAZYALIGN pragma (that is, the prgama itself) is something Olaf created and had nothing to do with me. I diagreed with it and never used it in the version of the compiler I ran. I support its removal. > On Feb 18, 2008, at 3:01 PM, Darko wrote: > >> The alignment behaviour is absolutely crucial to programming >> natively in Mac OS X and should be kept. I have a great need for it. >> >> The PRGAMA is of no use and can be removed. >> >> Does anyone have any objections to making this alignment behaviour >> standard? > > What do you mean make LAZYALIGN standard? Why wouldn't we go with > the standard gcc-backend alignment? Perhaps I don't understand what > it is you are doing or trying to do. Again, please remind me what it > is that LAZYALIGN does and why it is needed. > >> On 19/02/2008, at 4:36 AM, Tony Hosking wrote: >> >>> Can someone remind me again why we need LAZYALIGN? I concur with >>> Randy that if it is rarely used and moreso breaks things I would >>> argue to abandon it. >>> >>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote: >>> >>>> I use pickles extensively and they are used also by network objects. >>>> I've never used LAZYALIGN. >>>> My vote is that we don't break something (pickles/netobj) to add >>>> support for something that is rarely used. >>>> Regards, >>>> Randy >>>> >>>> >>> "Rodney M. Bates" 2/15/2008 5:06 >>>> PM >>> >>>> I'll put it in comments in the code. I am sure I can fix it to >>>> handle LAZYALIGN too, just not sure whether I can do it without >>>> requiring existing pickle files to be regenerated and/or existing >>>> code that reads/writes pickles to need recompilation. >>>> >>>> Anybody on this list who has code that might be affected if pickles >>>> or compiled code were invalidated by a change? >>>> >>>> I do propose we change the way of telling the compiler to do >>>> LAZYALIGN so that it is a property of a type and affects all >>>> variables of that type. >>>> >>>> Olaf Wagner wrote: >>>> > Perhaps we should check-in this description somewhere near the >>>> > actual code? Or is there enough documentation already? >>>> > >>>> > Olaf >>>> > >>>> > PS: Based on your description, I'd say we should abandon >>>> LAZYALIGN. >>>> > Or at least put a big sticker on that it will break pickles. >>>> > >>>> > Quoting "Rodney M. Bates" : >>>> > >>>> >> The word "Packing" in RTPacking is perhaps misleading. Using >>>> BITSIZE, >>>> >> etc. only works for getting object layouts as on the machine >>>> executing >>>> >> the code, which is all that is needed when writing a pickle. >>>> >> >>>> >> When reading, Pickle code needs to know the layouts of a type >>>> both as >>>> >> it is on the reading machine and as it was on the machine that >>>> wrote >>>> >> the pickle. The type description that the compiler generates is >>>> >> excerpted and contains no field displacements, just lists of >>>> field >>>> >> types (which are either recursive type descriptions or builtin >>>> types). >>>> >> So it is independent of word sizes, etc. >>>> >> >>>> >> Pickles regenerates the displacements using the few target >>>> machine >>>> >> characteristics in a RTPacking.T It traverses a type >>>> description and >>>> >> simultaneously computes two sets of field displacements, both >>>> as they >>>> >> are on the reading machine and on the writing machine. For >>>> the latter, >>>> >> the value of RTPacking.T is (after a compact bit encoding) >>>> stored in the >>>> >> header of the pickle file. For the former, it's gotten by >>>> techniques >>>> >> like >>>> >> using BITSIZE. This is actually all done in RTTipe, part of >>>> m3core, and >>>> >> called by Pickle code. >>>> >> >>>> >> This is very fragile. RTTipe has to duplicate the compiler's >>>> layout >>>> >> behavior. There is no shared code. Making it common would >>>> involve >>>> >> quite a bit of rework, as the two use substantially different >>>> data >>>> >> structure and code organization. It will be obvious what kind >>>> of bit >>>> >> damage could occur if the two algorithms didn't agree. >>>> >> >>>> >> This is why I am obsessing over LAZYALIGN. I have been >>>> comparing the >>>> >> field displacement computations in RTTipe and in the >>>> compiler. The >>>> >> former is oblivious to LAZYALIGN. >>>> >> >>>> >> Note that all this is required even without any packing of >>>> small fields >>>> >> within words. E.G., a record with two INTEGER fields, pickled >>>> on a >>>> >> 32-bit machine and unpickled on a 64. >>>> >> >>>> >> Tony Hosking wrote: >>>> >> >>>> >>> Rodney, >>>> >>> >>>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>>> >>> would have thought all packing is done on word-sized units >>>> anyway. >>>> >>> Each side of the connection can check BITSIZE(LONGINT) to >>>> figure >>>> >>> out what to do presumably no differently from the way >>>> INTEGER is >>>> >>> communicated between 32-bit and 64-bit machines. Am I missing >>>> >>> something? >>>> >>> >>>> >>> -- Tony >>>> >>> >>>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>>> >>> >>>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can >>>> help with? >>>> >>>> >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>> >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> >>>>> (which can vary independently of the size of INTEGER). >>>> >>>>> 2) Variable length values of subrange bounds found in type >>>> >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> >>>>> what the native word size can represent. >>>> >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added >>>> recently) >>>> >>>>> is not handled by Pickles. >>>> >>>>> >>>> >>>>> I have done some coding on this, but have been interrupted. >>>> >>>>> >>>> >>>>> Tony Hosking wrote: >>>> >>>>> >>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> ------------------------------------------------------------- >>>> >>>>> 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 >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >> >>>> >> -- >>>> >> ------------------------------------------------------------- >>>> >> 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 >>>> > >>>> > >>>> > >>>> > >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> 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 rodney.bates at wichita.edu Tue Feb 19 03:00:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Tue, 19 Feb 2008 02:00:36 -0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B9644F.1E75.00D7.1@scires.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> <47B60CE0.8050506@wichita.edu> <47B9644F.1E75.00D7.1@scires.com> Message-ID: <47BA3AC5.40907@wichita.edu> Just to clarify: I don't believe anything existing has to break. The worst scenario I can see is that you would have to either simultaneously upgrade the compiler, libm3, and libm3core (or else none of these) before recompiling & linking any code that reads or writes pickles. If libm3 and libm3core are dynamically linked in at runtime, you would have to recompile with an upgraded compiler at the same time as installing the upgraded dynamic libraries. Existing pickle files would not change. Also, mixtures of programs thus recompiled & linked and programs not recompiled/linked could exchange pickle files. Anything that (un)pickles records or objects that are LAZYALIGN would need the upgrade to work, but such programs are already broken. Randy Coleburn wrote: > I use pickles extensively and they are used also by network objects. > I've never used LAZYALIGN. > My vote is that we don't break something (pickles/netobj) to add support > for something that is rarely used. > Regards, > Randy > -- ------------------------------------------------------------- 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 rodney.bates at wichita.edu Sat Feb 23 04:43:22 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 23 Feb 2008 03:43:22 -0000 Subject: [M3devel] [Fwd: Re: <*LAZYALIGN*>] In-Reply-To: <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> References: <47BEE918.1060908@wichita.edu> <1E474378-253C-4484-813B-A747EF28051B@darko.org> <47BF462C.6060204@wichita.edu> <5E9C296E-E323-4274-AE1B-ABDFE3E39237@darko.org> Message-ID: <47BF99F0.9050402@wichita.edu> Yes, most of this is done in RTTipe. I tend to speak sloppily about this as "pickles", which are, I believe, the only client code of RTTipe in the CM3 distribution. Darko wrote: > Then I assume RTTipe needs to be fixed, and pickles and the alignment > are ok. > >-- ------------------------------------------------------------- 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 Sun Feb 24 16:11:44 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:11:44 +0100 Subject: [M3devel] Pathname.T extensions, was: Re: exposing both path name types? In-Reply-To: References: <20080223210323.ozvtfpivr4w04404@mail.elegosoft.com> Message-ID: <20080224161144.zgi5zplzk8sgcc8s@mail.elegosoft.com> Actually I think it's a good idea to provide platform-specific interfaces for pathnames in libm3. This way programs can use the common pathname abstraction in general and special features of target specific pathnames if they need to. Especially when programming in a mixed Windows/POSIX environment this will help to keep things simpler. I'd suggest something like this: extends Pathname.T <---- PathnamePosix.T <---- PathnameWindows/NTFS.T <---- PathnameCygwin.T <---- [PathnameDos/FAT.T] (probably no need currently) <---- [PathnameOS2.T] (probably no need currently) (An alternative hinted at above would be to name interfaces after the actual file systems; there could be different implementations for UFS, ZFS, NTFS, FAT, HFS, SMBFS, etc. then. This may go too far though.) Pathname.T should keep all the abstractions that are curently there; nothing must be changed syntactically or semantically. It may be extended by an equal predicate (and thus abstract from case differences if needed) and perhaps more useful methods (arcSeparatorChar/Text(), hasPlatformSpecificRoot(), ...). PathnameWindows.T could extend the functionality by methods for handling of drives and UNC syntax; PathnameCygwin.T could contain support for /cygdrive/... conversion etc. All Pathname modules should only depend on pure TEXT functions (i.e. not platform specific library calls etc.). All derived types should implement initialization methods for conversions: initFromPosix( PathnamePosix.T ) initFromWindows( PathnameWindows.T ) initFromCygwin( PathnameCygwin.T ) Specialized applications like the CM3 builder which are platform specific to a certain extend could then use standard function calls to convert between different pathname representations as needed. Again, I think we should first exactly define the interfaces, and then provide some unit tests. I'll see if I can find some old tests as a start. BTW, the quake functions that were part of the original proposal I sent to the list are not implemented in quake because they were not really thought over well; if there are implementations of these in M3 (sysutils), these are just historic relicts and probably not very general and powerful. What do the others think? Olaf Quoting Jay : > What is the idiom for this: > > Currently: > There is Pathname.i3. > PathnamePosix EXPORTS Pathname > PathnameWin32 EXPORTS Pathname > You can only have one in a link. > > It would seem possibly useful to have: > Pathname.i3 unchanged > PathnamePosix.i3 identical to Pathname.i3 (some what to avoid the > duplication?) > PathnameWin32.i3 identical to Pathname.i3 (ditto) > > On Posix targets: > PathnameWin32.m3 exports just PathnameWin32 > PathnamePosix exports both PathnamePosix and Pathname > > On Windows targets: > PathnamePosix exports just PathnamePosix > PathnameWin32 exports both PathnameWin32 and Pathname > > That is Pathname.Foo resolves statically at compile time to the > target-specific library. > PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available. > > These modules each import nothing, except Text. They do all their > string manipulation themselves. > > Olaf's recent Quake extensions document but don't implement > pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( > pn ) --> text > As long as pn is a fullpath, these are easy, I just wrote up > prototypes, haven't compiled them. > > I think these functions might suggest doing what I'm asking about as > well, maybe. > Or maybe you'd just convert and then never pick back apart. > > I have sleazed by for now by using subst_text / to \ and setting up > NTFS junctions. > In this way, I can cross build NT386 <=> NT386GNU either host, either target. > Had I not done anything, the linker interprets > /cygdrive/c/foo/bar.lib as a command switch and says it doesn't > understand it. > Not a big deal, but I think there might be some easy progress here. > > This is not just about Pathname. > > It is also about File. > Even though NT386GNU File is FilePosix, it would be useful to allow > the serial package to use FileWin32 instead. > But FilePosix and FileWin32 both reveal the same types. > It'd be nice if they could expose FilePosix.T and FileWin32.T and > then only one of them reveal File.T = FilePosix.T or File.T = > FileWin32.T, something like that. > > > - Jay > _________________________________________________________________ > Climb to the top of the charts! Play the word scramble challenge > with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Feb 24 16:32:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 24 Feb 2008 16:32:05 +0100 Subject: [M3devel] Revert cm3 to version 6 days ago In-Reply-To: References: <20080224134642.48e7fowms8ooowo8@mail.elegosoft.com> <20080224143053.fdtxd48fkskggws0@mail.elegosoft.com> Message-ID: <20080224163205.5tifr1misg0wog4g@mail.elegosoft.com> Quoting Jay : > Oh darn, inevitably that is not my final answer.. > more like attached.. Jay, the files seem to work OK on my FreeBSD system. But the tinderbox tests on birch and new have failed, in spite of my CVS revert; so please don't commit anything until I have found out what is wrong. It may take some time, because I'm expecting guests soon and won't be able to do much until tomorrow evening. Olaf > - Jay > > From: jayk123 at hotmail.comTo: wagner at elegosoft.comSubject: RE: Revert > cm3 to version 6 days agoDate: Sun, 24 Feb 2008 14:20:03 +0000 > > > Olaf can you try the attached? Thanks, - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Feb 27 03:49:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2008 21:49:50 -0500 Subject: [M3devel] text inefficiency? good mutable string type? arrays? In-Reply-To: References: Your message of "Sun, 24 Feb 2008 01:59:03 +0100." <1203814743.7865.25.camel@hias.m3w.org> <200802242224.m1OMOUg8082647@camembert.async.caltech.edu> <6C4C7D60-B4A3-4960-A7E2-81318579085A@cs.purdue.edu> Message-ID: On Feb 26, 2008, at 6:46 PM, Jay wrote: > Tony, what about the need to copy? The inability to iterate through > characters without a function call per character? I guess though, > from what you pointed out, a read only direct pointer is viable. And > that removes the 256 character stack usage -- which is a bit piggy > as it is. So then..I guess the next step in some compromise here is > that it should perhaps be viable to get a read only pointer to a > string (maybe already the case), compute the required size of the > new one (follows naturally), and then be able to split up allocation > and filling in of a string, a function to allocate and get a direct > pointer, then fill in your data, then "seal" the text making it read > only. And I guess really you can just carefully use the "subversive" > method here -- up to you to not pass the "unsealed" text off to > anyone else until you are done writing to it. Have you looked at TextConv.i3? Not sure if that has some of what you are needing. > Then just to deal with the varying representation but as I was > suggesting, maybe that can be forced somehow. > Maybe creation can specify an encoding, or the "get buffer" function > could -- though ideally there is just one, not two. > > The stack vs. heap behavior is also not ideal in that it's nice for > the performance of something to scale linearly with input, not > suddenly slow way down when data exceeds some arbitrary threshold. > Granted, a lot of code just starts failing, so merely slowing down > is "progress". As well, eventually you end up swapping to disk, if > you don't first run out of address space, so there will be limits at > which things slow down or fail, just that they ought to be fairly > large. Why do you think that heap allocation is slow in general? > I also rather hoped/assumed that compile time text constants were > formed constant-ly by the compiler, that the compiler knows their > runtime layout. I realize the division of labor between compiler and > runtime can be made at varying points, with varying resulting > flexibility, but also varying resulting efficiency. Compile-time literals *are* formed constantly by the compiler. They are TextLiteral.T. > > > - Jay > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Tue, 26 Feb 2008 17:43:17 -0500 > Subject: Re: [M3devel] text inefficiency? good mutable string type? > arrays? > > I suppose the question here is how often you exceed the 256- > character stack-allocated buffer size? If not often then > occasionally allocating in the heap is not a huge problem. I'm not > too fussed about this anyway because generational GC will quickly > reclaim things that die as young as this buffer does. I think you > underestimate the effectiveness of modern GC algorithms. Anyway, > optimizing here for short nm texts presumably handles the common > case. Why work hard to optimize the uncommon case? > > On Feb 25, 2008, at 10:38 AM, Jay wrote: > > I know this area has been brewing under the surface a while. > I'll bring it up. :) > > Here is some apparently typical code: > > PROCEDURE Escape (nm: TEXT): TEXT = > VAR len: INTEGER; buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (nm = NIL) THEN RETURN NIL; END; > len := Text.Length (nm); > IF (len + len <= NUMBER (buf)) > THEN RETURN DoEscape (nm, len, buf); > ELSE RETURN DoEscape (nm, len, NEW (REF ARRAY OF CHAR, len + > len)^); > END; > END Escape; > > PROCEDURE DoEscape (nm: TEXT; len: INTEGER; VAR buf: ARRAY OF > CHAR): TEXT = > VAR n_escapes := 0; src, dest: INTEGER; c: CHAR; > BEGIN > Text.SetChars (buf, nm); > FOR i := 0 TO len-1 DO > IF (buf[i] = BackSlash) THEN INC (n_escapes); END; > END; > IF (n_escapes = 0) THEN RETURN nm; END; > src := len - 1; > dest := src + n_escapes; > WHILE (src > 0) DO > c := buf[src]; DEC (src); > buf[dest] := c; DEC (dest); > IF (c = BackSlash) THEN buf[dest] := BackSlash; DEC (dest); > END; > END; > RETURN Text.FromChars (SUBARRAY (buf, 0, len + n_escapes)); > END DoEscape; > > > Look at how inefficient this is. > For a long string it makes a heap allocation, even if in the end it > makes no changes to the string. > For any length string it copies it out to an array. > Then if there are any changes, it copies it again, probably into > heap, likely the input immediately becoming garbage. > Heap allocation may be fast, but building up garbage and causing > more work for the garbage collector I assume is bad. > And if the string had no backslashes, it's all a big waste. > > I assume texts are read only? > > I know lots of systems have read only strings. > There are pluses and minus to them. They can be single-instanced. > Some systems with read only strings have another type, such as > "StringBuilder" or "StringBuffer". > > > So -- I don't have a specific question, but maybe a mutable string > "class" aka "type" is needed? > Not necessarily in the language but in m3core or libm3? > Maybe it's already there? > > I just spent a few hours diddling with arrays of chars. > Unfortunately they are not resizable. > It was not entirely satisfactory. Besides the array I had to pass > around a length and a start. > Wrapping this up in one record TYPE MutableString= ... might be a > good idea. > > For more efficient read only access, would it be reasonable for the > runtime to materialize on-demand 8 bit and 16 bit representations of > a string if a user calls some new thing like Text.GetDirectA (t: > TEXT) : REF ARRAY OF CHAR, Text.GetDirectW (t: TEXT) : REF ARRAY OF > WIDECHAR? Throw an exception if the string cannot be represented > with 8 bit characters? Or use utf8? > > Besides, I know I'm a big predictable whiner but I like how this > works in Windows.. > It may not have been as seamless, but it works and it really doesn't > tend to break or slow down existing code. > roughly: > "foo" is an 8 bit string of type char* (or const char* or possibly > const char[4]) > L"foo" is an 16 bit string of type wchar_t* (ditto, and aka WCHAR) > "L" for "long" aka "wide" > > Functions must be written to specifically use one or the other. > In C++ you can templatize. There is std::string and std::wstring > that are template instantiations. > Lots of C functions are duplicated. strcpy => wcscpy, strcat => > wcscat, etc. > And really there's no point in 8 bit strings. > If you have a blob, that's an array of bytes or something, not > characters. > > It works. > > Utf8 is another seemingly popular route but I think it's a hack. > I think mostly people don't touch their code and say, voila, it's > utf8, and they only really support the same old English or possibly > 8 bit characters (some European characters). > Granted, to some extent, this does work, as long as you don't do > anything with the string but strlen, strcpy, and some others and > pass it to code that does treat it correctly. Still, variably sized > encodings seem like a bad idea here, and 16 bits per character seem > affordable enough. And yes, I know that Unicode is actually know 20 > bits per character and some characters take two wchar_ts but I try > to ignore that... > And I know there is a lot of existing code, but sometimes there is a > need for progress too... > > Ok, maybe NOW I'll look at the cygwin/shobjgen problem. :) > > > - Jay > > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 02:59:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 01:59:51 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: If this must be a switch, what should the default be? I suspect the default should be full paths. And then, should there be switches for each of: debuginfo assertions webinfo "assertions" actually use the Modula-3 equivalent of __FILE__. And so, what this should perhaps looks like is, using bogus Cish names, __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) __LEAF_FILE__ (e.g. fooposix.m3) or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch. I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing). - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info] Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available.. - Jay > From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail?- > >> get your "fix". Check it out. >> >> >> > -- > > -------------------------------------------------------------> > 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> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 29 03:00:38 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 29 Feb 2008 02:00:38 +0000 Subject: [M3devel] FW: put full paths to source files in debug info] In-Reply-To: References: <47C705FE.7090005@wichita.edu> <40D46F19-4400-4E08-966A-834446D5FAE1@cs.purdue.edu> Message-ID: (sorry for the double, email problems) From: jayk123 at hotmail.com If this must be a switch, what should the default be? _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: